Applied Design Patterns with Java
Behavioral :: Strategy (315) {C ch 24}
Implementation
The following implementation issues are relevant to the
Strategy pattern:
- Defining the Strategy and Context
interfaces. The Strategy and
Context interfaces must give a ConcreteStrategy efficient access to any data it needs from a context, and vice
versa. One approach is to have Context pass data in parameters to Strategy operations - take the data to the strategy. This keeps Strategy
and Context decoupled. On the other hand, Context might pass data the Strategy doesn't need.
Another technique has a context pass itself as an argument, and the Strategy requests data from the context explicitly. Alternatively, the Strategy
can store a reference to its context, eliminating the need to pass anything at all. Either way, the Strategy
can request exactly what it needs. But now Context must define a more elaborate interface to its data, which couples
Strategy and Context more closely. The needs of the particular algorithm and its data requirements
will determine the best technique.
- Strategies as template parameters. In C++ templates can be used to configure a class with a Strategy.
This technique is only applicable if (1) the Strategy can be selected at compile-time, and (2) it does not have to be
changed at run-time. In this case, the class to be configured (e.g., Context) is defined as a template class that
has a Strategy class as a parameter: The class is then
configured with a Strategy class when it's instantiated. With templates, there's no need to define an abstract class
that defines the interface to the Strategy. Using Strategy as a template parameter also lets you bind a Strategy to its Context statically, which
can increase efficiency. Java does not currently support templates,
but offers a functional equivalent by use of the Object type as a template placemarker type.
- Making Strategy objects optional.
The Context class may be simplified if it's meaningful
not to have a Strategy object. Context checks to see if it has a Strategy object before
accessing it. If there is one, then Context uses it normally. If there isn't a strategy, then Context carries out
default behavior. The benefit of this approach is that clients don't have to deal with Strategy
objects at all unless they don't like the default behavior.
Related Patterns
The
Flyweight (195): Strategy objects often
make good Flyweights.
Catalog Behavioral Prev Next