Strategy Pattern
- is a behavioral design pattern that lets you define a family of algorithms that “solve” the same thing, put each of them into a separate class, and make their objects interchangeable
Code Structure
|
|
Example Implementation
// 1. Define the interface of the algorithm
interface Strategy {
void solve();
}
// 2. Bury the 2 implementations
class Implementation1 implement Strategy {
public void solve() {
// implementation 1 here
}
}
class Implementation2 implement Strategy {
public void solve() {
// implementation 2 here
}
}
// 3. Define user of Strategy interface (with no view of implementation)
class Context {
private Strategy strategy;
public Context(Strategy strategy) { this.strategy = strategy; } // Dependency Injection happens here
public void setStrategy(Strategy strategy) { this.strategy = strategy; } // Dependency Injection happens here
public void doSomething() { strategy.solve(); }
}
// 4. Using it as Client
public static void main( String[] args ) {
Context context = new Context(new Implementation1());
context.doSomething(); // executes implementation #1
context.setStrategy(new Implementation2());
context.doSomething(); // executes implementation #2
for (Strategy algorithm : algorithms) {
algorithm.solve();
}
}
Comparisons to Other Design Patterns
Click here to expand...
Link to originalBridge Pattern vs Strategy Pattern
- the UML class diagram for the Strategy is the same as the diagram for the Bridge. However, these two design patterns aren’t the same in their intent. While the Strategy pattern is meant for behavior, the Bridge pattern is meant for structure
- the coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern
Link to originalStrategy Pattern vs Dependency Injection
- Strategy Pattern focuses on intent and encourages you to create an interface with different implementations that obey the same behavioral contract
- Dependency Injection is more about just having an implementation of some behavior and providing it
Link to originalStrategy Pattern vs State Pattern
- in State Pattern, particular states are aware of each other
- in Strategy Pattern, strategies are almost never aware of each other
Link to originalCommand and Strategy may look similar because you can use both to parameterize an object with some action. However, they have very different intents.
- Command Pattern can be used to convert any operation into an object. The operation’s parameters become fields of that object. The conversion lets you defer execution of the operation, queue it, store the history of commands, send commands to remote services, etc
- Strategy Pattern usually describes different ways of doing the same thing, letting you swap these algorithms within a single context class
Link to originalStrategy Pattern vs Template Method Pattern
- Template Method Pattern is based on inheritance: it lets you alter parts of an algorithm by extending those parts in subclasses
- Strategy Pattern is based on composition: you can alter parts of the object’s behavior by supplying it with different strategies that correspond to that behavior
- Template Method Pattern works at the class level, so it’s static after compile-time
- Strategy Pattern works on the object level, letting you switch behaviors at runtime
/behavioral-design-patterns/strategy-pattern/strategy-pattern-structure.png)