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
Tuesday 27 March 2007
Sunday 25 March 2007
Decorator Pattern
Decorator Pattern
In short the Decorator Pattern allows responsibilities to be assigned to an object without sub-classing and add the responsibilities dynamically to the object. Decorators provide a flexible alternative to sub-classing for extending functionality.
Decorator Pattern addresses the limitation of inheritance. Inheritance adds behaviour to an object at compile time where decorator provides a new behaviour to an object at runtime.
Inheritance can be used where the sub classes can be predicted while with the decorator such predictability is not required.
The main advantage of the Decorator pattern is that it avoids extensive sub-classing.
Other advantages of using the Decorator Pattern include:
The ability to develop more elegant programmes as too many sub-classing are removed. This further makes it easy to maintain the application.
The Decorator also provides the capability to add new functions to an object without affecting other objects. All other objects remain intact during developing or during maintenance of the application.
Decorator Pattern makes it possible to easily add or remove responsibility from an object dynamically.
Decorators can be recursively nested without any other objects being able to tell the difference, allowing a near infinite amount of customization.
Make ones code more flexible. Decorating is more flexible than plain, old static inheritance. With the decorator pattern, one can add, any number of decorators to a particular component.
The Decorator pattern keeps things simple. When using the decorator pattern, one does not have to complex classes that consider every possible scenario. With the Decorator Pattern, one only needs to design a simple abstract class and then decorate the class as necessary. One can further develop new concrete decorators without disturbing the original design of the application.
Demerits of the Decorator pattern
Identity crisis problem: Decorators wrap themselves around components. They therefore change the identity of the component onto which they wrap themselves. The resulting component is not therefore the same as the original component. One therefore needs to be careful about object identity whenever reference is made to one of the decorated components.
The other problem is Object Critters.
Even with the decorator pattern, one can still have too many classes, especially concrete decorator classes. This is the same problem the inheritance has.[1]
In this section the differences between Decorator Pattern and other patterns namely: Adapter, Proxy, Composite, and Strategy is examined
Decorator Vs Adapter
The Adapter Pattern provides a different interface to the object it adapts, whereas decorator changes the object’s responsibilities or simply provides an enhanced interface to the subject.
When compared to Adaptor Pattern, the Decorator Pattern is more transparent to the client. The other difference between the Adapter and Decorator Pattern is that the Decorator Pattern support recursive composition, which is not possible with pure Adapter Pattern.
Decorator Vs Proxy Pattern
Proxy Pattern and Decorator Pattern have different purposes but similar structures. The main similarity between the two is that they both describe how to provide a level of indirection to another object, and the implementations keep a reference to the object to which they forward the request.
Proxy pattern however, controls access to the object whereas a decorator adds additional responsibilities to an object.
Decorator Vs Façade Pattern
Façade pattern provides a way of hiding a complex class, whereas decorator adds function by wrapping a class.
Decorator Vs Composite pattern
Composite and Decorate when examined closely have similar structure diagrams, which re-enforces the fact that both rely on recursive composition to organize an open ended number of objects. Further examination of the Decorator and Composite Patterns shows that decorators can be viewed as a delegate Composite with only one component.
The Composite Pattern’s focus is not on embellishment but on representation. This makes the intent of both patterns complementary. [2]
[1]
Barry Burd and Micheal P Redlich
Decorator Pattern
(2007)
http://javaboutique.internet.com/tutorials/decorator/index-4.html
Accessed: 22nd March 2007
[2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Design Patterns,
Elements of Reusable Object-Oriented Software,
1995
Addison-Wesley
Pages 219 -220
In short the Decorator Pattern allows responsibilities to be assigned to an object without sub-classing and add the responsibilities dynamically to the object. Decorators provide a flexible alternative to sub-classing for extending functionality.
Decorator Pattern addresses the limitation of inheritance. Inheritance adds behaviour to an object at compile time where decorator provides a new behaviour to an object at runtime.
Inheritance can be used where the sub classes can be predicted while with the decorator such predictability is not required.
The main advantage of the Decorator pattern is that it avoids extensive sub-classing.
Other advantages of using the Decorator Pattern include:
The ability to develop more elegant programmes as too many sub-classing are removed. This further makes it easy to maintain the application.
The Decorator also provides the capability to add new functions to an object without affecting other objects. All other objects remain intact during developing or during maintenance of the application.
Decorator Pattern makes it possible to easily add or remove responsibility from an object dynamically.
Decorators can be recursively nested without any other objects being able to tell the difference, allowing a near infinite amount of customization.
Make ones code more flexible. Decorating is more flexible than plain, old static inheritance. With the decorator pattern, one can add, any number of decorators to a particular component.
The Decorator pattern keeps things simple. When using the decorator pattern, one does not have to complex classes that consider every possible scenario. With the Decorator Pattern, one only needs to design a simple abstract class and then decorate the class as necessary. One can further develop new concrete decorators without disturbing the original design of the application.
Demerits of the Decorator pattern
Identity crisis problem: Decorators wrap themselves around components. They therefore change the identity of the component onto which they wrap themselves. The resulting component is not therefore the same as the original component. One therefore needs to be careful about object identity whenever reference is made to one of the decorated components.
The other problem is Object Critters.
Even with the decorator pattern, one can still have too many classes, especially concrete decorator classes. This is the same problem the inheritance has.[1]
In this section the differences between Decorator Pattern and other patterns namely: Adapter, Proxy, Composite, and Strategy is examined
Decorator Vs Adapter
The Adapter Pattern provides a different interface to the object it adapts, whereas decorator changes the object’s responsibilities or simply provides an enhanced interface to the subject.
When compared to Adaptor Pattern, the Decorator Pattern is more transparent to the client. The other difference between the Adapter and Decorator Pattern is that the Decorator Pattern support recursive composition, which is not possible with pure Adapter Pattern.
Decorator Vs Proxy Pattern
Proxy Pattern and Decorator Pattern have different purposes but similar structures. The main similarity between the two is that they both describe how to provide a level of indirection to another object, and the implementations keep a reference to the object to which they forward the request.
Proxy pattern however, controls access to the object whereas a decorator adds additional responsibilities to an object.
Decorator Vs Façade Pattern
Façade pattern provides a way of hiding a complex class, whereas decorator adds function by wrapping a class.
Decorator Vs Composite pattern
Composite and Decorate when examined closely have similar structure diagrams, which re-enforces the fact that both rely on recursive composition to organize an open ended number of objects. Further examination of the Decorator and Composite Patterns shows that decorators can be viewed as a delegate Composite with only one component.
The Composite Pattern’s focus is not on embellishment but on representation. This makes the intent of both patterns complementary. [2]
[1]
Barry Burd and Micheal P Redlich
Decorator Pattern
(2007)
http://javaboutique.internet.com/tutorials/decorator/index-4.html
Accessed: 22nd March 2007
[2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Design Patterns,
Elements of Reusable Object-Oriented Software,
1995
Addison-Wesley
Pages 219 -220
Subscribe to:
Posts (Atom)