5.4. Implementing an Interface

Remember, the Styleable interface is just the contract. We also need to have at least one class that implements (signs) the contract. We will use two different implementing classes to demonstrate that the implementation (method) specifics are up to the implementing class (not the interface). The interface simply ensures that each implementing class has a certain set of methods.

In Java, a class can implement an interface using the implements keyword, e.g., as seen in Fancy.java.

public class Fancy implements Styleable {

In this example, Fancy is the implementing class that has signed the Styleable contract. It signs the contract as soon as you add implements Styleable to the class declaration as seen above. Again, Fancy will not compile unless it has a concrete (non-abstract) implementation of both the style and unstyle methods, which it currently does.

Note

If the interface is not in the same package as the implementing class, then you will need to add an import statement or use the fully qualified name of the interface. If more than one interface is being implemented, then they can be written in a comma-separated list following the implements keyword.

Take a moment to inspect the source code for the cs1302.interfaces.impl.Fancy class. You will see both of the abstract methods from Styleable implemented. Notice that the implementations contain method bodies (instead of their signatures ending with a semicolon). A specific example can be seen with the unstyle() method:

public void unstyle() {
   styled = false;
} // unstyle

The implementation is short but that’s okay! The purpose of this method is simply to change the styled instance variable of the calling object to false. This will ensure that any subsequent calls to toString will not return a styled version of the message.

Note

As mentioned earlier, it is syntactically correct for an abstract method in an interface to omit the public keyword. If omitted in the interface, the method is still assumed to have public visibility.

However, the implementation of such a method in an implementing class will need to include the public visibility modifier. It cannot be left off in this context.

Learn by Exploring!

Now, take a moment to compare the Javadoc comments in the source code for the Styleable interface with the comments written in the source code for the implementing Fancy class. In some cases, new comments are provided. In others, it appears as though Javadoc comments are omitted. In the latter case, this is actually not true. View the API documentation website for both the Styleable interface and the Fancy class — bring them up side-by-side, if possible. All of the methods in Fancy are documented, even style() and unstyle() which have no Javadoc comments in the source code!

This happens because the Javadoc tool has the ability to inherit comments from an interface when omitted or when explicitly requested in the implementing class’s Javadoc comment using the {@inheritDoc} tag. Pay close attention to the difference between these two scenarios, both in the source code and in the generated API documentation website.