In this blog post, Justin Albano talks about the basic Strategy pattern and the “fundamental principles that make for solid strategy implementations.” He also goes into the use of Dependency Injection (DI) “to select a strategy implementation” along with a walkthrough of a basic payment system using the Strategy pattern.
The purpose of the Strategy pattern is “to decide the algorithm used in a specific context” by encapsulate algorithms into classes with the same interface, and by using the same interface, we allow the algorithms to be interchangeable based on what is needed. The following is a UML class diagram of the Strategy pattern:
The way the author makes sense of the Strategy pattern is to see the Context class as a desk, “where the Strategy interface represents a slot in the desk that accepts drawers” and each the concrete strategy implementations “can be thought of as actual drawers, where some are completely undivided, and others have various divider configurations; some may be good at storing papers, while others may be better at organizing pens, pencils, and paper clips. Each serves its own purpose and excels in a specific context, but vary only in their internal configuration: The external configuration of each drawer is the same so that it can be accepted by the desk.”
I selected this article because I wanted to learn more about the Strategy patterns, and design patterns as a whole. This post had topics that I didn’t know about like Dependency Injection, using the Introduce Parameter Object refactoring technique. It also goes well into detail an implementation of a payment system showing both the Strategy pattern and Factory pattern. I feel my knowledge of the Strategy pattern has improved after reading this article, and seeing it implemented in a new way helps me understand it more. The author is very detailed and explains the topic clearly. I learned about the importance of selecting the appropriate strategy, whether it’s more appropriate to have a run-time selection (a conditional run-time selection will require logic whose complexity is proportional to the number of possible concrete strategies) or a static selection (Strategy is selected once when the application starts-up and is never reinitialized for the duration of the execution of the application. I plan on using the Strategy pattern when I am developing software, the Strategy pattern has many uses in the world of software development and will continue to be utilized.