To build the shifter String, notice that we took the key and placed it in the beginning. Then, we go through the characters in our encodable range and add them if they are not already in the shifter string. In the following example, note that the shifter string starts with "DEF" $($the key$)$ and then is followed by the encodable range in its original order, excluding characters $\text{'}$D$\text{'},\text{'}$E$\text{'},$ and $\text{'}$F$\text{'}$ as they're already in the shifter. After creating the shifter string, the process of encrypting and decrypting should exactly match that of the Substitution cipher $($replace each character of the input with the character at the same relative position in shifter for encrypting, or vice$-$versa for decrypting$)$ Hint: Notice how after creating the shifter String, encrypting and decrypting a given input behaves exactly the same as Substitution $!$ Keeping in mind our recently learned concepts, what can we say about the relationship between the CaesarKey and Substitution ciphers? How can we take advantage of those similarities to reduce redundancy between these two classes? At this point, we recommend taking a closer look at the provided example if you haven't done so already! Expand Required Behavior CaesarKey should extend the provided Cipher.java OR a subclass of Cipher.java and contain the following constructor: public CaesarKey$($String key$)$ Constructs a new CaesarKey with the provided key value This constructor should throw an IllegalArgumentException if the given key meets any of the following cases: Is empty Contains a duplicate character Any individual character falls outside the encodable range $(<$ Cipher.MIN$\_$CHAR or $>$ Cipher.MAX$\_$CHAR $)$ public