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

void setOrigin(Point newOrigin);
boolean draw(Point drawOrigin);
...
}
Now suppose that we have a separate interface in which we define the activity of the Cowboy
objects that are going to be part of our program:
public interface Cowboy {
boolean ride(Horse toRide);
boolean rope(Cow toRope);
boolean draw(Point toShoot);
...
}
Our Cowboy objects do the usual things that cowboys do. They ride (or try to ride) horses.
They rope cows. But they also get into gunfights, where they have to draw their pistols and
fire at some particular point.
But now we want to build a new computer game with a Wild West theme, and we need to
define a class:
public class GraphicalCowboy implements GraphicsObject, Cowboy {
...
}
As in our previous example having to do with baseball statistics, we find that we have a meth-
od with the same name and signature defined in two different interfaces that are implemented
by the same class. In this case we want very different implementations for the two methods.
But given the type system of Java, we can't; there is only one Draw() method, even at the
GraphicalCowboy level.
This problem is caused because Java interfaces do not create a separate namespace, and hence
there is no way to disambiguate the draw() that is defined in the Cowboy interface from the
draw() that is defined in the GraphicsObject interface. The methods have the same name,
take the same argument, and return the same value. So from the Java point of view, they must
be the same. [ 8 ] It doesn't have to be this way. It would have been possible to define Java in-
terfaces so that they created their own namespace, and we could distinguish between Graph-
icalObject.draw() and Cowboy.draw() in the same way that we can use packages to dis-