UML Weekend Crash Course™ - To Parent Directory

136
Saturday Afternoon
Table 12-3
The State Design Pattern Example
Pattern Element
A problem to solve
The resources to solve it
The set of rules about how
the resources could be
used to solve the problem
Guidelines to know when
the pattern works well
and when it does not
Element Description for State Pattern
You need to create a Product class for the Inventory Control
System. The Product will be used in a number of different
steps within the system. Depending on where a Product is in
the workflow, each method on the Product may or may not be
valid. Also, some methods might need to behave differently
during different steps in the workflow.
The state design pattern has two resources, in this example
they are the Product, which provides the context, and the
Product State (state), which defines the state-specific implementations
for each method. Figure 12-3 illustrates the Class
diagram for this relationship.
The rules for the state design pattern dictate two roles: the
context, which is provided by the Product class, and the state,
which is provided by the Product State class. The Product State
is actually a generalization of classes that define the individual
states for Product and their state-specific implementations
for each operation.
The Product receives requests in the course of normal business.
But rather than implement the requested operations, it delegates
or forwards each request to an instance of a ProductState
subclass that represents the current state of the Product. The
ProductState instance performs the implementation that it
owns for the operation and returns control to the Product. As
the state of the Product changes, each new request is actually
forwarded to an instance of a different ProductState subclass
that represents the current condition of the Product.
Many objects simply don’t have a significant number of states,
or their behavior doesn’t vary significantly from state to state.
Figure 12-3 shows the association “delegates to” between Product and ProductState. If
that were all the Class diagram showed you, then you wouldn’t really be able to tell why
they were associated. After all, Products are also associated with LineItems and Locations.
The association name may give you a clue, but when you add the pattern notation, you
immediately bring in all the information about how the pattern tells you to use these two
classes in this relationship. The pattern notation explains their communication, the methods
they need to support, and the attributes they will need in order to support the relationship
and the communication.