Strategy Pattern

Study of GoF's Design Patterns (1994)

Intent

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

Also Known As

Policy

Motivation

Don't hardwire algorithms to classes that require them. What happens if algorithm changes? What if many classes commonly use this algorithm? What if bug is found, and it needs to be changed? Avoid duplicate code and support different algorithms using the same interface.

diagram from book

In this case, Composition class uses Compositor class to call Compose(), which manipulates Composition's members. But which compositor it uses can vary, even at runtime.

Applicability

• Many related classes differ only in their behavior.
• Need different variants of an algorithm
• Algorithm uses data that clients shouldn't know about
• A class defines many behaviors, and these appear as multiple conditional statements in its operations. You can move these conditionals to their Own Strategy class.

structure

Participants

• Strategy (Compositor)
  - declares an interface common to all algorithms.
• ConcreteStrategy
  - implements algorithm
• Context (Composition)
  - is configured with a ConcreteStrategy object
  - has reference to a Strategy Object

Collaborations

• Context may pass relavant data or itself to Strategy to determine the algorithm. Passing itself also allows callback functionality.
• A context forwards requests from its clients to its strategy. Clients usually create and pass a ConcreteStrategy object to the context.

Consequences

1. Familes of related algorithms. Filter out common functionality using inheritance. Subclasses for specific algorithm, which can is reusable.
2. An alternative to subclassing.
3. Strategies eliminate conditional statements. yay.
4. A choice of implementations. Different algorithms, same behavior
5. Clients must be aware of different strategies. So, only use when the variation in behavior is relevant to clients
6. Communication overhead between Strategy and Context. Relevant info, or Context itself is passed. But some algorithms may not use all info, while some use all. If this is an issue, neee tighter coupling between Strategy and Context.
7. Increased number of objects. Sometimes can be avoided by implementing stateless objects that contexts can share. Refer to Flyweight pattern.

Implementation

1. Defining the Strategy and Context interfaces. Passing the Context itself couples it, but allows explicit request to Context from Strategy. Or you can pass data as parameters to decouple it, but then might pass data that some algorithms don't need. Choose wisely.
2. Strategies as template parameters. Some C++ stuff. If algorithm to use is decided at compile-time, and not changed during run-time.
3. Making Strategy objects optional. Check Context checks if Strategy objects exist. If not, carry out default behavior. if yes, use Strategy. Benefit is clients don't have to deal with Strategy objects at all, unless they don't like the default behavior.

Sample code

in book, C++.

Known Uses

Many known uses, but I know not one of these. Refer to book if needed

Related Patterns

Flyweight Pattern