One of the most useful design patterns is the Strategy pattern. Where variation in algorithm use is key, the Strategy pattern encapsulates the algorithms and uses delegation to handle requests. You can easily change algorithms by re-writing the code just for the algorithm. Adding algorithms is just as easy when the requirements for your application change because all of the code for the algorithm is encapsulated in separate objects (classes). So instead of having your algorithms scattered all over the place, the Strategy pattern organizes and encapsulates them.
To get started, take a look at the class diagram for the Strategy pattern. If you are familiar with the State design pattern, you’ll see that the class diagrams are identical, but do not assume that the patterns are the same because they are very different. When we discuss the State pattern, we’ll look at those differences, but for now, just focus on the Strategy pattern itself.
Figure 1: Strategy class diagram
All requests from the Client (not shown in the diagram) go through the Context class to the Concrete Strategies through the Strategy interface.
Before continuing you need to know that not only do design patterns use a lot of classes, but they are typically saved in separate files. When it comes time to update and re-use materials, this arrangement works quite well. Further, you have to place all of the files in the same directory—this was done to keep it simple, but feel free to change that into multiple directories and re-code the materials so that the links are updated. Save some time by downloading all the code and get an idea of what the program does by clicking on the appropriate button below:
Algorithm Writers’ Heaven
I’ve never met two PHP programmers who agree on the same algorithm for…well just about anything. This is the beauty of the Strategy design pattern. All of the algorithms are encapsulated, and so if you don’t like the algorithms, you can change them to suit your own style and wisdom. Further, if you decide to add functionality to a program or to change the functionality, you can simply change one of the algorithms without the whole house come crashing down around your ears. Of course the Strategy pattern was not designed for cantankerous PHP programmers who don’t like other’s algorithms but rather for programmers who have to deal with changing functionality in an application or several different algorithms from the same “family.” In effect, you set up an interchangeable set of algorithms by establishing an interface with the desired method(s) and control the whole operation through a context class.
The algorithms can vary independent of the client (Client class) who uses it. Further, the strategies eliminate the need for conditional statement. Instead of using a conditional to call a different algorithm, the strategies are encapsulated in separate classes (implementations of a strategy interface), and so they can be called directly by the client through the context.
What’s Wrong with Conditional Statements?
Let me just blurt it out :
I avoid conditional statements whenever possible.
Such a claim may seem to be a little odd since the Chain of Responsibility pattern uses them extensively. The handleRequest() method in all of the concrete Handler classes use conditional statements. That’s true, but the conditionals are all the same and only check to see whether the request can be handled by the current concrete handler or not. These operations are little checkers or inspectors that either handle to request or pass it along the chain. They’re not the kind that have to think about several alternatives.
Continue reading ‘PHP Strategy Design Pattern: Encapsulating Algorithms’
Recent Comments