The Saturation Plan: One's Bound to hit the Target
I was looking at John Lindquist’s fantastic video explaining the Strategy design pattern, and while I’ve been thinking about a slightly different tact for learning, it gave me an idea. Up to this point, Chandima and I have gone over lots of design patterns in varying levels of depth. However, what I think would help the developers on this blog learn design patterns would be to take just a few, one from each of the three main categories, and come at it from different angles. That is, saturate readers with lots of information and examples from just three patterns.
The Three Types of Patterns
The Gang of Four divide up design patterns into three types:
I realize that those names don’t mean jack unless they are viewed in terms of problem-solving. That is, what specific problems are addressed by each of these groupings of design patterns? So let’s start with a summary of the problems that design patterns address.
On pages 24-25 in their book, GoF discuss the common causes of redesign. What causes developers to tear apart a program and have to start over? Why can’t a class be re-used? Why can’t just a few things be changed to introduce something new? If you read those causes, you can better see the solutions to those problems. The following are the eight causes of redesign GoF specify that cause problems. Remember! This is a list of bad practices that Gang of Four have identified that prevent change and reuse of objects:
- Creating an object by specifying a class explicitly
- Dependence on specific operations
- Dependence on hardware and software platform
- Dependence on object representations of implementations
- Algorithmic dependencies
- Tight coupling
- Extending functionality by subclassing
- Inability to alter classes conveniently
Design Patterns are meant to address these various bad habits. For example, the Factory Method addresses the issue of creating an object by specifying a class explicitly. So you may be wondering—What’s wrong with that? How else could you create an object?
Most developers do not see the problem with explicit class creation. Simply stated, to do so can tangle you up in the particulars of the class. A commitment to a specific class leads to dependencies on the that class’ implementation. However, instead of committing to a class, commit only to an interface and use the other class through the interface. Then, if you want to make changes, you only have the interface, which cannot cause a dependency. Using the Factory Method, you create class instances indirectly through a factory. The factory creates the instance, and your Client uses the factory’s instance.
The Saturation Plan
To get this plan off the ground, I thought that a good place to begin would be with the Strategy pattern. The reason for choosing the strategy pattern is that because it specifically addresses more than one of the issues: Algorithmic dependencies and Extending functionality by subclassing. Everyone loves a good algorithm; but if a new one comes along that does a better job (like swapping in a Skip List for some other search algorithm), you don’t want to tear up your whole program to do so. You just want to tuck in the new algorithm where they old one was. Secondly, the Strategy pattern is one of the key patterns for using delegation. Any program that uses delegation over inheritance has fewer dependencies. Finally, the Strategy pattern is flexible so maybe developers can be weaned from the MVC long enough to get into a new pattern and move ahead in design patterns.
This is not an invitation to argue the best algorithm. For all I care, you can use a bubble sort—algorithms are not the issue. The issue is that we use and change algorithms so often that if we can do that with more flexibility; then redesign becomes easier. We’ll look at the Strategy pattern from so many different angles with several different posts, that you’ll be so inundated with it, you can’t help but understand it.
OOP and design pattern principles are like cheat sheets to understand design patterns and become a better programmer. If you haven’t gone over them lately, they’re all here for you. Go over them, and you’ll be part of the discussion and get more out of the saturation plan.
The comment section is for feedback. I’m going to initiate the plan in the next couple of weeks, but if this is not something you feel will be of any benefit for you or you have a better idea, let me know.