Strategy design pattern is used for selection of algorithm from a family of algorithms based on context or data.
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary
independently from clients that use it.
The intent is to encapsulate each algorithm of family and make them interchangeable based on context or data.
Client needs to select different algorithm based on request or data. Also it is difficult to add new algorithm if
implementation is part of client.
The client will have complexity to handle the algorithms and it will become hard to maintain. This will add lot of conditional
statements. Also modification in existing algorithm and addition or deletion will be difficult.
Make the selection of algorithm separate from implementation and encapsulate the implementation of different
algorithms in separate objects.
The separation of selection and implementation will provide flexibility. It will be easy to do the modification in selection
of algorithm. Also it will be good to have an easy way for addition or deletion of algorithm, and the modification of
algorithm will have no dependency on other modules.
Where it is applicable?
The selection of an algorithm is required from a family of algorithms.
To avoid multiple conditional statements for selection of algorithms and to hide its algorithm data structures and
complexity from client.
Context has instance of class Strategy. This may also provide interface for accessing its data so that strategy
can access it.
Strategy class provides interface AlgorithmInterface() for algorithms which is used by Context.
Concrete classes ConcreteStrategyA, ConcreteStrategyB and ConcreteStrategyC implement the method
AlgorithmInterface() to provide the algorithm.
How they work together?
Client creates the ConcreteStrategy object and passes it to Context. Context uses the Strategy interface to call the
method of ConcreteStrategy. Context may pass data to Strategy or may pass itself so the data can be accessed by Strategy.
Client chooses a ConcreteStrategy from a family of ConcreteStrategy classes and interacts with Context.
So the selection of algorithm is separated from implementation and each algorithm is encapsulated. This approach
reduces the subclassing and avoids having multiple conditional statements. It increases flexibility to add and remove the
algorithms and makes it easy to modify the existing ones. The client requires knowledge of all concrete strategy and has
to communicate with Context. Also as the number of algorithm grows, there will be increase in number of objects.
Suresh Kumar Srivastava is founder of online learning site coursegalaxy.com and author of popular books "C In Depth",
"Data Structures Through C In Depth". He has 18+ years experience in industry and worked on architecture and design of
multiple products. This article is from his courses on Design Patterns.
CourseGalaxy is focused on transformation of Engineering graduate to Software Engineer to fill the gap
between education and industry and provide the training on specific problems of industry to enhance the skills
of Engineers in industry to do their job appropriately.