Java Reference
In-Depth Information
will call the appropriate method for each child. If we want to add a new activity
with this organization, we have to change the code for every subclass. But this is
relatively rare for our text compositing application. In contrast, adding a new object
into the subclass hierarchy (which for this application is far more likely than adding
a new rendering function) is easy. Adding a new subclass does not require changing
any of the existing subclasses. It merely requires that we define the behavior of each
activity that can be performed on the new subclass.
This second design approach of burying the functional activity in the subclasses
is called the Composite design pattern. A detailed example for using the Composite
design pattern is presented in Section 5.3.1.
1.3.4
Strategy
Our final example of a design pattern lets us encapsulate and make interchangeable
a set of alternative actions that might be performed as part of some larger activity.
Again continuing our text compositing example, each output device that we wish
to render to will require its own function for doing the actual rendering. That is,
the objects will be broken down into constituent pixels or strokes, but the actual
mechanics of rendering a pixel or stroke will depend on the output device. We
don't want to build this rendering functionality into the object subclasses. Instead,
we want to pass to the subroutine performing the rendering action a method or class
that does the appropriate rendering details for that output device. That is, we wish
to hand to the object the appropriate “strategy” for accomplishing the details of the
rendering task. Thus, this approach is called the Strategy design pattern.
The Strategy design pattern can be used to create generalized sorting functions.
The sorting function can be called with an additional parameter. This parameter is
a class that understands how to extract and compare the key values for records to
be sorted. In this way, the sorting function does not need to know any details of
how its record type is implemented.
One of the biggest challenges to understanding design patterns is that some-
times one is only subtly different from another. For example, you might be con-
fused about the difference between the composite pattern and the visitor pattern.
The distinction is that the composite design pattern is about whether to give control
of the traversal process to the nodes of the tree or to the tree itself. Both approaches
can make use of the visitor design pattern to avoid rewriting the traversal function
many times, by encapsulating the activity performed at each node.
But isn't the strategy design pattern doing the same thing? The difference be-
tween the visitor pattern and the strategy pattern is more subtle. Here the difference
is primarily one of intent and focus. In both the strategy design pattern and the visi-
tor design pattern, an activity is being passed in as a parameter. The strategy design
pattern is focused on encapsulating an activity that is part of a larger process, so
