Strategy Pattern (also known as the policy pattern), Simple and useful, it’s a very simple pattern I went through. Even though it’s simple it is gaining great weight to best coding practices.
Official Definition
“Define Family of Algorithms, encapsulate each one, and make them interchangeable. Strategy let’s algorithm vary independently from client that use it”.
Why we need pattern like this
If you see how horrible lengthy if else statements or switch statements, that is one of the reason where strategy pattern come to the screen. Normally a program is such a sequence of Logical Operations; here operation itself might be simple algorithm. In Object Oriented Programming, we have classes and inside a class we are having methods where we writing particular sequence of operations to achieve some business aspect. In business flow, to take the decisions to getting invoke some operations in execution sequence, are doing at run time according current state. So there you need If-else statements or switch statement to manage that.
Every programmer should dream to write their code as a story, Code reviewers would love to give best comments on that definitely.
This is such simple story which might love to read by especially maintenance people, they won’t be having any harm to understand this. Business process too explaining in method itself, no one need to go back and see use cases and all when maintenance are doing on the code. In Such a business workflow, we might be having more than this if-else statements or lengthy switch statement. Yes, suppose we wrote the logic as nice readable story, but still it’s having too many lengthy logical statements.
Here is Context class where actually Calculation business aspect implementations is been used.
While having such switch statements in the business logic implementations, you are taking risk of frequently changing when new business aspect is asked to be added to the flow. Suppose in this case, someone is asking to added another Calculation Operation into the business logic and then you need to do two things primarily
- Add new Item into the enum
- Add new case
statement into the switch statement
With this example it seems no any harm to do that, but when business scenarios getting large, you might be having bit complex business flows. Same thing can occur in lengthy if-else statements too. This is the place where Strategy Pattern comes to the screen. Basically it will allow you to add new business aspect to the business workflow or change existing business aspect in flow, without touching existing business workflow. With that you won’t need to add new item to emun and add new case statement to the switch.
Strategy Pattern
If you have written the business logic as a good readable story which itself explain the Algorithm associated with it clearly, and then it is the time to think about Strategy Pattern to enhance code design to support future changes. Identify the Algorithm is extremely vital with this pattern and extract Algorithm signature into an Interface is the second step. Then Client will only couple with Algorithm Interface and burry implementation details into derived classes. Then Client won’t be having any harm on adding new derived classes to extend the business and or change derived classes on requirement changes. Here is the check list you might help to identify and do stuff.
- Identify an Algorithm that client need to access.
- Code signature for that algorithm in an Interface.
- Burry alternative implementation details in derived classes.
- Clients of the algorithm couple themselves to the Interface
Calculation Interface
Just interface Operation need to be done to achieve particular business aspect. Particular calculation should implement ICalculation interface and implement Calculate Method
By implementing ICalculation Interface, implicitly we implement calculate method and it’s subject to that particular Calculation. Here it’s Add two values and return result back. Then Calculation class would look like this with new method
And Context class (Calculation User class) is going to be like this
Implementation is looking great after new method than earlier. But advantage is not only that, suppose you need to Use another Calculation in the context. Then
- You don’t need to touch Calculation Business workflow implementations. It means don’t need to changes Calculation class or ICalculation Interface.
- Just need add another Calculation Operation class like “Modulation” while implementing it ICalculation interface.
- In the “UseCalculation” Method, you can use instance of newly created class to achieve new Calculation Operation in existing system without changing main business workflow.
Found good Diagrams explaining concept well
Here we can remind one another such important concepts in design pattern like “Program to interface and not to an implementation” and “Open for extension and close for modification”. Implicitly it has been followed by us on this. Here we concern only business logic implementation and not on Context implementation where Business Logics are been used. Our main concern should be on securing business logic from ambiguous implementations.
Conclusion
Strategy Pattern might have been followed by us without knowing even it’s the Strategy Pattern. This posting was about mentioning things bit clearly.
Resources
Head First Design Patterns
http://en.wikipedia.org/wiki/Strategy_pattern
http://jeremyjarrell.com/archive/2007/10/28/64.aspx
http://www.dofactory.com/Patterns/PatternStrategy.aspX
http://www.developer.com/tech/article.php/3683091
http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx
http://www.primaryobjects.com/CMS/Article70.aspx
http://blog.cumps.be/design-patterns-strategy-pattern/
http://sourcemaking.com/design_patterns/strategy
Regards
Lakmal Kankanamge