Minimalist Abstract State Pattern | 361the Play Button. In a typical video player application, the player will start over again. In
that application, thestartPlay( )method is as dumb as a bo xof rocks. However,
because polymorphism allows multiple forms of the same method, it allows us to pro-
vide the application with multiple forms that know what to do in different contexts. So
in the Play state, the method knows it’s already playing, and so it does nothing. A user
can pound on the Play Button all he wants, and the video just keeps on playing. He can
press the Stop Button, and the video will stop, just like it’s supposed to do.
To better appreciate polymorphism, you will see that as more states are added to the
application, there’s more to keep track of. With more methods, we absolutely, posi-
tivelydo notwant to modify the wrong thing. Without polymorphism, we run the risk
of having the same method do something we definitely do not want it to do. Thus, if
you don’t want your application to start playing video all over again every time the
startPlay( )method is invoked, using the State design pattern, you can structure the
application to only start at the beginning when the originating state is the Stop state.
Likewise, you can structure thestartPlay( )to begin playing all over again from the
Play state—you write the code, and so you control how the methods behave.
When you read the next chapter on the Strategy design pattern, you may have a
major case ofdéjà vu. The juxtaposition of these two chapters is no accident. Once
you complete the example applications in each chapter, you should definitely get a
different feel for each, even though the structures look very similar. The State design
pattern has its focus on the states and well-defined transitions. This is one reason we
use statecharts—they help clarify and simplify the architectural work in focusing on
the different states and how they transition from one to another. The transitions in
the State design can be controlled by the states themselves or by the context class.
Also, because the State design creates a class for each state (behavior environment),
you tend to generate more classes with the State design than with the Strategy
design. Determining which behavior to use is delegated to the State classes, while the
Strategy pattern encapsulates a family of algorithms and allows them to vary inde-
pendent of the client within the structure that uses them.
Minimalist Abstract State Pattern
Using the State design pattern, all the behaviors (methods) for a single state are
placed into single objects (concrete states), and all transition behaviors for the appli-
cation (state machine) are placed into a single interface. Each state object imple-
ments the interface in a fashion appropriate for the state. Because of this structure,
no conditional statements are required to branch differentially depending on the cur-
rent state. Rather than writing comple xconditional statements, the individual state
objects define how the methods are to behave for that state.