Strategy Pattern — The General of Design Patterns
Design patterns are solutions implemented to fix commonly occurring problems in the software world. One of the most well-known patterns is the Strategy pattern. Strategy is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.
Strategy suggests to pick a class that does something specific in several ways and extract the algorithms into different classes called strategies. The selected class must have a field that will reference to the chosen strategy. By doing so, the class will delegate the task to the strategy instead of executing itself. It is important to highlight that the class itself won’t select the appropriate algorithm, but the client passes the desired strategy to be triggered instead.
If you see that adding more variants to your class creates complexity, then you know it is a code smell since it may lead to future conflicts. That huge class can become a complete mayhem. This is where strategy saves lives since it simplifies the workflow by decomposing into higher and lower levels. Now, that leads to a very important question that is when is the strategy pattern applicable?
When is the Strategy pattern applicable? — Refactoring Guru
- When you want to use different alternatives of an algorithm within an object and want to switch from one algorithm to another during runtime.
- When a class has several algorithms that contain something in common, but each one still has a behavior that distinguishes it from the others.
- When you want to isolate the business logic from the implementation details of algorithms that aren’t relevant in the context of the logic.
- When your class has a gigantic conditional operator that switches between different alternatives of the same algorithm.
Structure of Strategy — Refactoring Guru
- The Client creates and passes the strategy object to the context.
- The Context maintains a reference of the passed strategy and communicates with this object through the Strategy interface only.
- The Strategy interface is common to all Concrete Strategies and it declares the method the context uses to execute a strategy.
- Concrete Strategies implements different variations of an algorithm the context uses.
Here’s the fun part: The Keurig example. Let’s say that Keurig launched their first version that only makes black coffee. Their first version is a success, and customers start asking for more options such as cappuccino, latte, and cortados. Per customers’ requests, they added these beverages on their next version: The Keurig 2.0. When adding these options, the developers noticed that the main class started to grow significantly and it could lead to conflicts.
As an approach to solve this mess, they decided to apply the strategy pattern. So whenever an order came in, it would get the right strategy provided by the client.
Structure for The Keurig example
- The Client creates and passes the coffee strategy object to the context such as Cappuccino, Latte or Cortado.
- The Context maintains a reference of the passed strategy (coffeeStrategy) and communicates with this object through the Strategy interface only. Keep in mind that the context doesn’t know what kind of strategy it’s working with nor how the algorithm is executed.
- The Strategy interface is common to all Concrete Strategies and it declares the method (prepareCoffee) the context uses to execute a strategy.
- Concrete Strategies (Cappuccino and Latte) implements different variations of an algorithm the context uses.
As you can see in the image attached above, the client will provide the correct strategy to be used by the context. Then, the context will delegate the work to the strategy object to make the right beverage. By doing this, it avoids doing multiple versions of the algorithm on its own.
The output would be:
Here’s the github repository for the example provided above: https://github.com/afloresmorales/strategy-dp.
