* The number of assists (total) for this player.
* @return the assists, as an integer
* The number of fielding attempts by this player.
* @return The attempts, as an integer
* The number of errors committed by this player.
* @return the number of errors, as an integer
* 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
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.