Introducing Responsibility - Design Patterns Java - page 65

One feature that makes a class easier to use is that its method names suggest, accurately, what
the methods do. However, you have seen some exceptions to this principle in challenges from
earlier chapters.
CHALLENGE 7.3
Give an example of when the effect of calling a method differs from the behavior
implied by the method's name.
Establishing principles for the proper assignment of responsibility in object-oriented systems
seems to be an area ripe for progress in computer science. A system in which every class and
method clearly defines its responsibilities and bears them correctly is a strong system,
probably stronger than most systems we encounter today.
It is common to speak of classes and methods as bearing various responsibilities. In practice,
this usually translates into your bearing responsibility for the solid design and proper
functioning of your code. Fortunately, Java offers some relief. You can limit the visibility of
your classes, fields, and methods and thereby limit your responsibility to developers who use
your code.
Controlling Responsibility with Visibility
Consider the SolidRocket simulation class shown in Figure 7.2. This class's constructor
requires four parameters that establish a rocket's thrust. (The figure shows only the burn rate
parameter; the other parameters are the specific impulse, propellant density, and burn area of
the rocket.) Suppose that you own the simulation package and have a habit of declaring
instance variables with the protected modifier. This policy lets other classes in your
package access a SolidRocket instance's fields without having to call get- methods. This
is somewhat risky, as you have to understand, for example, that changing the burn rate in
a simulation means that you have to recalculate a rocket's thrust.