Strategy Pattern

In this blog I look at the Strategy Pattern, its applicability, strengths and weakness, and how it differs from other patterns

Strategy Pattern defined

The strategy pattern defines a family of algorithms, encapsulate each one, and make them interchangeable. [1] This pattern lets the algorithm vary independently from clients that use it. The different algorithms will be appropriate at different times.

The main benefit of Strategy Pattern is that if one wants to add a new algorithm, it can be added easily without disturbing the application using the algorithm.

Strategy is also known as Policy.


When to apply the Strategy Pattern

The Strategy pattern is used in the following situations:

Encapsulate various algorithms to do more or less the same thing. This makes the program easier to maintain. For example, one can simply add or remove an algorithm without affecting the rest of the application.

Strategy is also used where one needs one or several algorithms to be implemented in an application dynamically.

Strategy helps avoid exposing complex and algorithm-specific structures to the rest of the application. This feature again makes application maintenance much easier.

With Strategy Pattern multiple conditional statements are reduced. Instead of using multiple conditional statements, algorithms are encapsulated each in its separate object. This reduces the number of loops in the application therefore enhancing the performance of the application.

Just like the decorator pattern, Strategy provides alternatives to sub-classing. This therefore overcomes some of the weaknesses associated with inheritance.

When applying Strategy Pattern please watch out!!!

Despite at advantages of Strategy Pattern, it has the following limitations

As the number of algorithm increases in an application, the number of objects also may increase. This can be a set back to the strategy pattern as too many objects are introduced in the application.

Just a thought, in case there are many algorithms, can the program spend too much time trying to work out which algorithm to use? Or is best for the given context? If the answer this is yes, then I think it’s not a good idea to have too many algorithms as the application take too long trying to work out the best suited algorithm.


Differences between Strategy and other patterns
In this section I compare Strategy pattern with other patterns namely: State, Flyweight, Decorator and Composite

Strategy Vs State

State Pattern activates several states of an object, whereas strategy can only activate one of the algorithms. Therefore the scope of the Strategy is limited only to algorithms with no reference to states of a given object.

Strategy Vs Flyweight

Flyweight provides a shared object which can be used in multiple contexts simultaneously, whereas strategy focuses only on one context.

Decorator Vs Strategy

Decorator pattern changes the skin of the object while Strategy changes the gut of an object. Strategy is a better choice in situations where the component class is intrinsically heavyweight, thereby making the decorator pattern too costly to apply.

According to the GOF, by extending the number of strategies from just one to an open-ended list, we achieve the same effect as nesting decorator recursively.

Composite Vs Strategy

Composite is used to combine a strategy to improve efficiency.

It ought to be noted that State, Strategy, Bridge and Adapter have similar solution structures. They all share elements of the “handle/body” idiom. They differ in intent of course; that is they solve different problems.

It becoming more clear, the more patterns we cover the more I have come to realise that no one pattern is an island. Last week I thought the Decorator Pattern had it all. This the Strategy is seemingly more interest, well, lets see what next week has. One lesson I have learnt is to first cover all the patterns and them make a judgement. But still it will be hard I think to come out will the best pattern.

They all look good, do not they???

References:

[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Design Patterns,
Elements of Reusable Object-Oriented Software,
(1995)
Addison-Wesley
Page 315 - 323