Design Pattern - Strategy

http://en.wikipedia.org/wiki/Strategy_pattern

 

Intent:

1. Define a family of algorithms, encapsulate each one, and make them interchangeable.
2. Strategy lets the algorithm vary independently from clients that use it.
3. Policy

Applicability:

1. Classes differ only in their behavior.
2. Different variants of an algorithm.
3. Algorithm uses data that clients shouldn't know about.
4. A class defines many behaviors. 

Structure:

 

Participants:

Strategy 

1. declares an interface common to all supported algorithms. 
2. Context uses this interface to call the algorithm defined by a ConcreteStrategy.

ConcreteStrategy

1. implements the algorithm using the Strategy interface.

Context

1. is configured with a ConcreteStrategy object.
2. maintains a reference to a Strategy object.
3. may define an interface that lets Strategy access its data. 

Overview:

1. Strategy and Context interact to implement the chosen algorithm.
2. A context may pass all data required by the algorithm to the strategy when the algorithm is called.
3. Alternatively, the context can pass itself as an argument to Strategy operations. That lets the strategy call back on the context as required.
4. A context forwards request from its clients to its strategy.
5. Client usually create and pass a ConcreteStrategy object to the context; thereafter, clients interact with the context exclusively.
6. There is often a family of ConcreteStrategy classes for a client to choose from.
7. Families of related algorithms.
8. An alternative to subclassing.
9. Strategies eliminate conditional statements.
10. A choice of implementations.
11. Clients must be aware of different Strategies.
12. Communication overhead between Strategy and Context.
13. Increased number of objects.

Applications:

1. Compositor
2. SimpleCompositor, TeXCompositor, ArrayCompositor
3. Composition