Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
The final design pattern I'll demonstrate is the strategy pattern. A strategy pattern consists of a group of interchangeable algorithms that perform tasks, then a mechanism to choose which algorithm to use. That all sounds a bit complex, right? Let's apply it to an everyday task. When I get up in the morning, I need to decide what shirt I'm going to wear. I'll look at my stack of clothes. There is a RED SHIRT that's dirty and a BLUE SHIRT that's clean. For each shirt, I have to decide if it will work. I can't wear the RED SHIRT, because it's dirty, but I can wear the BLUE SHIRT, because it's clean.
If both shirts are clean, I could prefer the RED SHIRT over the BLUE SHIRT. None are clean? I've run out of strategies, and now I am going to have to do laundry. In the Exercise Files, I've included an example of a strategy pattern for displaying an address. There are four files. First, the AddressDisplay class defines an interface with the methods that implementing classes must use for displaying an address. In particular, it has a Boolean method to determine if the strategy can be used, then the display method itself.
AddressDisplayNoCountry will cleanly render an address without a country. I am going to use this within other display classes. AddressDisplayFull builds upon the previous address, and displays a full address, including the country. This display method uses DisplayNoCountry to avoid duplicate code. Finally, AddressDisplayPark, which displays the address with a green background, with and without a country. I'm going to change the Address class to use the strategy pattern for display.
First, I need to add a constant for an error, in case there are no strategies available. Const ADDRESS_ERROR_NO_DISPLAY_STRATEGY = 1002. Then, after the property definitions, add a static property that will contain an array of class names of the display strategies. Order them by the least to most preferred. private static _display_strategies = array, AddressDisplayNoCountry, followed by AddressDisplayFull. And then, the most preferred.
AddressDisplayPark. After the display strategies, add a private property that will be used to store the last found display strategy. private _display_strategy. Next, go to the Display method, and remove the existing contents. Use the Lazy initialization Singleton pattern for determining which display strategy to use. If is_null this->_display_strategy foreach of the self _display_strategies as this strategy_class_name.
If the strategy is available, if strategy _class_name::isAvailable with a context of this, this->_display_ strategy = the strategy_class_name. If no strategies are available, throw an exception address using the error code defined earlier. throw new ExceptionAddress No display strategy found, followed by the error code. self::ADDRESS_ERROR_NO_DISPLAY_STRATEGY.
Finally, set a variable with the name of the display strategy, then call the static method for the display. return display_strategy::display $this. Save the Address class, then open the AddressPark class. Remove the overriding display method; it's no longer needed. Then, save AddressPark. Return to the browser, and refresh. Each address should display. Experiment with a demo by changing address types and data to see all the variations. In this chapter, I explored three different object-oriented design patterns that were used to build this application.
I started with a Singleton pattern, which limited the number of database connections, then moved on to the factory method pattern for creating addresses without having to know the subclass, and finally, the strategy pattern for intelligently choosing how to display an address. Of course, there are dozens of additional patterns that you can use. In the final chapter, I'm going to discuss some of the directions you can take in learning more about object- oriented PHP, which includes design patterns.
Get unlimited access to all courses for just $25/month.Become a member