5.1. Introduction

In its simplest form, a Java interface is a reference type composed of abstract methods and constants. As a starting point, you can think of it as a special type of class that limits what it can contain. An abstract method is a non-static (instance) method without an implementation (body). Think of creating a class, adding the method signatures, but not putting any code in the methods. This will seem strange at first but the benefit will become clear as you learn more. Constants are variables (static or not) that are declared using the final keyword.

As of Java 8, the technical definition for an interface allows it to contain only the following: abstract methods, constants, private methods, static methods, nested types, and default implementation methods ([INTERFACE]). In 1302, our interfaces will mostly contain only abstract methods and constants. Nested types and default methods will not be covered in this course.

Now that we know what interfaces can contain, it’s also important to understand that interfaces are used to specify that a class can do a set of things specified by its abstract methods and constants. An interface serves as a contract for the classes that implement the interface. Multiple classes can implement the same interface, each providing its own implementation of the contracted functionality. For this reason, the documentation for an interface must describe what a method does and not necessarily how it should do it. Such documentation is usually written using Javadoc comments in the interface.

This may all still seem a bit strange and why we do this in programming has not yet been made clear. Hang in there! Let’s work through an example in Java. Try to keep this terminology in mind as you work through this tutorial.

Real World Example

Remember, we said an interface is a contract for the classes that implement it. Take a moment to think about how contracts are used in the real world (forget Java for a minute).

Hopefully, you came up with a definition of the word contract and maybe a few situations where contracts are used.

In the real world, we think of a contract as a formal and binding agreement between two or more parties. Let’s use the professional athlete as an example. Athletes sign a contract which is a binding agreement between the athlete and the team/organization that ensures the athlete will compete in his/her sport. The contract states that the athlete must “compete” but it doesn’t say specifically how they will compete. The details of exactly how an athlete should compete are usually not mentioned in the contract. Those details are left up to the athlete to decide during competition and the coaches during practice. The contract simply binds the athlete to compete.

Contracts to compete are signed by various types of athletes: track athletes, baseball players, football players, race car drivers, etc. Again, the signer determines the details of how they will compete. The contract only binds them to the action of competing.

Now, let’s tie this back to programming. Remember, methods are like actions that can be performed on objects and interfaces are like contracts. In the example above, compete is the abstract method that could be placed in a Competable interface (for lack of a better name). The abstract method represents the action that is required of the signer of the contract. In other words, the method is what the signer is obligated to do when they agree to implement the interface (a.k.a. sign the contract). The implementation details of the compete method are not given in the interface itself but instead, they are written in the implementing class (signer). Again, the implementing class (contract signer) can be any type of athlete as they are all required to compete.