The Type System - Java: The Good Parts - page 18

Then, of course, there are times when you are defining some class that is internal glue to some
implementation you have, or that is needed inside of some code that you didn't write but need
to fix. Spending the time to build an appropriate abstraction in the form of an interface may
not be needed or even justified in these conditions. Like everything else in software, there are
no absolute design rules, and good design requires judgment on the part of the designer. But
not defining the interface, and not using that interface in method declarations, should be the
exception rather than the rule.
Beware
Although the type system in Java is a great aid in building large-scale software, there are some
features of the system to avoid (we will see them in a moment), and others that are, at best,
odd. We will look at one of the oddities first. This is an aspect of the type system that could
trip up a design (although it rarely does).
We can see an example of what I am talking about in our baseball statistics package. In this
package we have two interfaces, the Batter and the Fielder interface, that both have a meth-
od declared as:
String getName();
which is supposed to return the name of the player whose statistics are being held in the object
that implements the interface. The methods have the same signature; they each take no argu-
ment and they each return a String . If we have some class that implements both of the in-
terfaces, we need to know how to deal with a single method that is defined in two different
interfaces.
For this case, the way the Java language works corresponds nicely to our intuitions. What the
Java language says in this case is that there is really only one method to be implemented, even
though it is defined in two different interfaces. The getName() method in the two interfaces
is really the same method.
Although this works fine in this case, we can think of others where it would be more of a
problem. Consider an interface for a graphical object, which defines methods to get and set
the origin of the object, and one to make the object appear on the screen:
public interface GraphicsObject{
Point getOrigin();