An interface is a way to describe how to interact with a class that implements defined methods. An interface only defines how to interact with an interface or class that implements the interface, not the actual implementation. In other words, an interface exposes what behaviors will be available, not how the behavior is carried out. In the real world, all cars have horns, but each car’s horn may have a distinct volume, pitch, sound, and duration. The interface for each car may be the same (pressing the center of the steering wheel), but the sound produced by each car (the implementation) is different. This allows any driver to know how to use any car horn, not how the sound is produced by the internals of the car.
An example can be found in the java.sql package, or JDBC (Java Database Connectivity) API (Application Programming Interface), of the Java programming language. Each vendor JDBC driver implements the Statement interface . So, when using JDBC, one can create the appropriate SQL (Structured Query Language) statement and use the same Java code without modification, because the vendors that have fully implemented JDBC drivers have implemented all the methods defined in the Statement interface. Even though MySQL, Oracle, and SQLite all have differing ways to store and retrieve data, the developer only needs to be concerned with one way to access the data that is vendor agnostic through the Statement interface methods.
We can create our own example of the usage of interfaces to further illustrate the points made. Suppose we have an application that has various document types that will be printed in different ways. We can create a class called Document, that allows us to name the document. The constructor for each document type can, we need to, override how to set the name of the document. Since we also need to write each type of document differently, we define an interface that requires each document to provide a write method. Each type of document will be expected to implement the write method.
We can create a class diagram describing the API we just described.
As you can see, the Document class is abstract and implements the Writebale interface. We made the Document class abstract because, for the purposes of the API, we want a concrete class created for each instance of a document type (ex. Pdf and Text). To instansiate the Document class on its own defeats the purpose of the API. The compiler will issue an error if the API is not properly used, which is what we want. In order to have a valid contract (an expectation of how the API operates), we must have rules that are enforceable and intuitive to the person using the API. Another reason to use an interface. If a method is left implemented, the compiler issues an error stating there are unimplemented methods, thus enforcing the idea of design by contract. The Document class, since its abstract, does not need to implement the methods in the Writeable interface, because an abstract class will not be instantiated, it only provides a super-class to be sub-classed.
We can create an example program to demonstrate the usage of an interface.
Copyright 2012 James G. Willmore
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
* @author James G. Willmore
public class Test
* The main method.
* @param args the arguments
public static void main(String args)
Document pdf = new Pdf("a.pdf");
Document txt = new Text("text.txt");
As you can see, a developer does not need to worry about how to print differing document types. This task is addressed in the way each document type implements the write method. This frees the developer to write code focused on the business problem versus how to account for each type of document encountered. Creation of a document type only requires the extension of the Document class. The class sub-classing Document must provide the proper implementation for the write method.
- An interface defines common behavior(s) that is expected within an API, but not the implementation of the expected behavior
- The expected behavior is implemented within each class implementing the interface
- The existence of the expected behavior is enforced by the compiler at compile time
- Enforces the idea that there is a contract between the developer using the API and the API’s maintainer on the expected usage of the API (design by contract)
Sample code is available for download and review.