Java Reference
In-Depth Information
* The number of assists (total) for this player.
* @return the assists, as an integer
*/
int getAssists();
/**
* The number of fielding attempts by this player.
* @return The attempts, as an integer
*/
int getAttempts();
/**
* The number of errors committed by this player.
* @return the number of errors, as an integer
*/
int getErrors();
/**
* Return the name for this player. Note that the interface
* does not define how the name is set; this is done when
* an object implementing this interface is created.
* @return the name of the player, as a String
*/
String getName();
}
This interface defines a set of statistics that can be explained in terms of each other, but none
of them need to refer to the statistics defined in the
Batter
interface. So we do have inde-
pendent units of meaning, which helps to validate our design. We can further validate this sep-
aration by realizing that, while most
Player
objects will implement both of these interfaces,
there is no necessary connection or requirement that they do. Not all batters need to be fielders
(especially in the American League, but even in the National League there are players who
are only pinch-hitters). Not all fielders are hitters (pitchers in the American League). More
importantly, the semantics surrounding the statistics of hitting have nothing to do with the se-
mantics of the statistics that relate to fielding. So we define the two in separate interfaces,
mixing them in those implementations where both are needed, but keeping them conceptually
separate in our design.
Once we start thinking this way, we see that there are a number of other relationships that
we can capture in the type system. All catchers, for example, are fielders, but there are other
fielding statistics we might want to track (such as passed balls) that apply only to catchers.
