Java Reference
In-Depth Information
face implemented by a class, the reasoning went, added an extra level of indirection to call the
methods that were defined in the interface. The runtime performance of calling through an in-
terface, on this view, was not something that the designers were willing to pay. But even in the
early days of the Java interpreter, when acceptable performance was a real concern, this was
such a minor optimization that it didn't really make much sense. With the current performance
of just-in-time compilers, this objection makes no sense at all.
A second efficiency argument that is often presented against the use of Java interfaces has to
do not with the runtime efficiency of the program, but with the coding-time efficiency of the
programmer. On this argument, interfaces are to be avoided because they duplicate inform-
ation in the system, requiring the programmer to do more code entry and create more files.
Why declare an interface, such arguments go, when all of the information about the method
names, input parameters, and return values will just have to be typed again when implement-
ing a class that implements that interface?
Such thinking misses the importance of interfaces to good systems, and shows a failure to un-
derstand how interfaces are part of what makes the type system in Java one of its best features.
The interface defines an abstraction that a class implementing that interface makes concrete.
Different classes may make the interface abstraction concrete in different ways, but they still
have the abstraction that is captured by the interface in common. That Java has a way of ex-
pressing what these different implementations have in common is a strength of the language,
not a weakness.
The need for the declaration of the methods that appear in an interface to be duplicated in the
classes that implement the interface is also a strength rather than a weakness. By separating
the declaration of the method signatures from the class that implements the method, the com-
piler can find those cases where a programmer changes the signature of a method or makes
a typo in the name of the method. Further, you can trust that the other programmers on your
team are using the same interface definition because all the classes that implement a particular
interface will share a common definition. Even the objection that this split between defining
interface and implementing class causes extra typing is mitigated by modern integrated de-
velopment environments (IDEs), which will automatically insert the proper code in your class
files.
It is in the declaration of the arguments and return values of a method that the notion of an
interface can first be seen as important. The compiler requires that the objects passed into a
method or returned from the method be of the declared type. But those objects don't need to
be exactly of that type; they are required only to be of
at least
that type. If the type is one that
is defined by a class, then any object that is an instance of a subclass of that class can be used.
This means that you can pass a subclass into a method that is declared as taking objects of
