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

1. Add new Item into the enum
2. 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.

1. Identify an Algorithm that client need to access.
2. Code signature for that algorithm in an Interface.
3. Burry alternative implementation details in derived classes.
4. 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

1. You don’t need to touch Calculation Business workflow implementations. It means don’t need to changes Calculation class or ICalculation Interface.
2. Just need add another Calculation Operation class like “Modulation” while implementing it ICalculation interface.
3. 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

• How you arrange your class structure
• Deciding your class structure and which responsibilities are going to assign each other class
• How you control access to each and every classes, methods, properties and variables
• And etc..

Design Principle

“Identify the aspect of your application that vary and separate then from what stays same.”

It’s like this, suppose some aspect of you application is changing with new requirements, then it’s obvious you got behavior that need be pulled out and separated from all the stuff that doesn’t change. Other way round it’s like, take parts that vary and encapsulate them, so that later you can extend or alter the parts that vary without affecting that don’t.

Almost all the Design patterns are coming save this concept. All patterns provide a way to let “some part of a system vary independently of all other parts”.