Strategy
JaninaVoigt (Talk | contribs) |
JaninaVoigt (Talk | contribs) |
||
| Line 9: | Line 9: | ||
There are several reasons that this can be useful. | There are several reasons that this can be useful. | ||
| + | * Many related classes only differ in behavior. | ||
* There are several different versions of the algorithm to implement. | * There are several different versions of the algorithm to implement. | ||
| − | * The algorithms are used in more than one place. [[Once and only once]] | + | * The algorithms are used in more than one place. (See [[Once and only once]]) |
| − | * There is a need to create an encapsulation boundary around the algorithm to hide implementation details. | + | * There is a need to create an encapsulation boundary around the algorithm to hide implementation details. This can for example be useful when the algorithm uses data that clients shouldn't know about. |
| − | * The class using the strategy implements many different behaviours choosing which behaviour to use with ''if'' statements. Each choice can be represented as a strategy instead simplifying code and making the intent explicit. | + | * The class using the strategy implements many different behaviours choosing which behaviour to use with ''if'' statements. Each choice can be represented as a strategy instead simplifying code and making the intent explicit. |
| − | + | ||
| − | + | ||
== UML Diagram == | == UML Diagram == | ||
Revision as of 02:47, 25 July 2009
Contents |
Intent
"Define a family of algorithms, encapsulate each one, and make them interchangeable" [GoF] That means to capture the abstraction in an interface and bury implementation in derived class, so that it lets the algorithm vary independently from clients that use it depending on the context.
When to use it
The strategy pattern is useful when there is a need to separate the implementation of a process from the class that uses it. There are several reasons that this can be useful.
- Many related classes only differ in behavior.
- There are several different versions of the algorithm to implement.
- The algorithms are used in more than one place. (See Once and only once)
- There is a need to create an encapsulation boundary around the algorithm to hide implementation details. This can for example be useful when the algorithm uses data that clients shouldn't know about.
- The class using the strategy implements many different behaviours choosing which behaviour to use with if statements. Each choice can be represented as a strategy instead simplifying code and making the intent explicit.
UML Diagram
Example
An Example would be a tax program, where you have different methods of calculating the taxrates depending on the country.
TODO: elaborate on example and add UML diagram
Strategy vs State
The State pattern in terms of design is quite similar to the Strategy pattern, but they differ in the way they are used. While in the derived classes of the strategy pattern most of the times just one different algorithm is implemented, the derived classes of the state pattern usually represent an independent state of something. That means they have their own fields, methods and so on.
Recognising the pattern
Classes: Strategy, multiple ConcreteStrategies, Client
- Strategy interface that contains public abstract execute() method.
- multiple ConcreteStrategy classes that implement the Strategy interface.
- Client class(es) that call the execute() method in Strategy interface.
- Not the Decorator pattern.
Related Patterns
See also
| Design patterns | |
|---|---|
|
Creational: Abstract Factory | Builder | Factory Method | Prototype | Singleton | |
