Design Patterns Java™ Workbook

Appendix B. Solutions

Introducing Responsibility (Chapter 7)...................................................................................................

SOLUTION 7.1.......................................................................................................................................

Some problems with the given diagram follow:

• The Rocket.thrust() method returns a Rocket instead of a number or a physical
  quantity.


• The LiquidRocket class has a getLocation() method, although nothing in the
  diagram or in the problem domain suggests that we model rockets as having a
  location. Even if we did, there is no reason for liquid-fueled rockets to have a location,
  whereas other Rocket objects do not.


• The isLiquid() method may be an acceptable alternative to using the
  instanceof operator, but then we'd expect the superclass to also have an
  isLiquid() method that would return false.


• CheapRockets is plural, although class names are conventionally singular.


• We could model cheapness with attributes alone, so there is no justification for
  creating a class just for cheap rockets. The CheapRockets class also introduces a
  factoring that conflicts with factoring the rocket model as liquid or solid. For example,
  it is not clear how to model a cheap liquid rocket.


• The CheapRockets class implements Runnable, although this interface has
  nothing to do with cheap rocket objects from the problem domain.


• The model shows that Firework is a subclass of LiquidRocket, declaring that all
  fireworks are liquid rockets, which is false.


• The model shows a direct relation between reservations and types of firework,
  although no such relation exists in the problem domain.


• The Reservation class has its own copy of city, which it should get by delegation
  to a Location object.


• A CheapRocket is composed of Runnable objects, which is simply bizarre.

SOLUTION 7.2.......................................................................................................................................

The value of this challenge is not to get the right answer but rather to exercise your thinking
about what makes up a good class. Consider whether your definition addresses the following
points.

• A nuts-and-bolts description of a class is, "A class is a named collection of fields that
  hold data values and methods that operate on those values" (Flanagan 1999b, p. 61).


• A class establishes a collection of fields: that is, it defines the attributes of an object.
  The attribute types are other classes, primitive data types, such as boolean and int,
  or interfaces.


• A class designer should be able to justify how a class's attributes are related.


• The name of a class should reflect the meaning of the class both as a collection of
  attributes and with respect to the class's behavior.


• A class must support all the behaviors it defines, as well as all those in superclasses,
  and all methods in interfaces that the class implements. (A decision to not support
  a superclass or an interface method is occasionally justifiable.)


• A class should have a justifiable relationship to its superclass.