Interfaces

Methods are also declared in interfaces. A method declared in an interface does not define the actual behavior of the method; they do not contain the code. They have only the head of the method; in other words, they are abstract implicitly. Although nobody does, you may even use the abstract keyword in an interface when you define a method.

Interfaces look very similar to classes, but instead of using the class keyword, we use the interface keyword. Because interfaces are mainly used to define methods, the methods are public if no modifier is used.

Interfaces can also define fields, but since interfaces cannot have instances (only implementing classes can have instances), these fields are all static and they also have to be final. This is the default for fields in interfaces, thus we do not need to write these if we defined fields in interfaces.

It was a common practice to define only constants in some interfaces and then use these in classes. To do that, the easiest way was to implement the interface. Since these interfaces do not define any method, the implementation is nothing more than writing the implements keyword and the name of the interface into the header of the class declaration. This is bad practice because this way the interface becomes part of the public declaration of the class, although these constants are needed inside the class. If you need to define constants that are not local to a class but are used in many classes, then define them in a class and import the fields using import static or just use the name of the class and the field.

Interfaces can also have nested classes, but they cannot have inner classes. The obvious reason for that is that inner class instances have a reference to an instance of the enclosing class. In the case of an interface, there are no instances, so an inner class could not have a reference to an instance of an enclosing interface, because that just does not exist. The joyful part of it is that we do not need to use the static keyword in the case of nested classes because that is the default, just as in the case of fields.

With the advent of Java 8, you can also have default methods in interfaces that provide default implementation of the method for the classes that implement the interface. There can also be static and private methods in interfaces since Java 9.

Methods are identified by their name and the argument list. You can reuse a name for a method and have different argument types; Java will identify which method to use based on the types of the actual arguments. This is called method overloading. Usually, it is easy to tell which method you call, but when there are types that extend each other, the situation becomes more complex. The standard defines very precise rules for the actual selection of the method that the compiler follows, so there is no ambiguity. However, fellow programmers who read the code may misinterpret overloaded methods or, at least, will have hard time identifying which method is actually called. Method overloading may also hinder backward compatibility when you want to extend your class. The general advice is to think twice before creating overloaded methods. They are lucrative, but may sometimes be costly.