It’s funny what you can learn when you actually pay attention, isn’t it. It turns out that for the last 10 years or so, I’ve not been the best programmer I could be. Now, I never had any grand illusions that I was the best there was. I know well and good there are many areas of my professional life that could be dramatically improved, but recently I was kind of thrust in to a world I thought I was already pretty well versed in. Boy, how wrong I was!
I’ve been aware of what Design Patterns are for the better part of the last 6 or 7 years or my career. In fact, we started loosely implementing some of them while I was still in New Zealand working for Black Sheep Creative. As it would turn out, however, I didn’t really learn their application very well and kinda strayed off the beaten path some what.
Design Patterns: What they aren’t.
Before we can define what Design Patterns are, we need to know what they AREN’T!
Design Patterns are NOT hard solutions for specific problems. Design Patterns lay the blueprints for common solutions to common problems. Adhering rigidly to them is often counter-productive, because they tend to add a layer of complexity to your code. That complexity, when unwarranted could actually make good code bad and bad code even worse!
Design Patterns are NOT the be all and end all of solutions. In fact, knowing about Design Patterns doesn’t actually improve your code immediately. Why? Because know what they are and know when and where to use each of them is not always clear. Applying them incorrectly, as mentioned above, could make things much worse!
Design Patterns, or rather the use of them is NOT a guarantee of success. I know I’ve said this twice before, but Design Patterns don’t actually give you anything for free. Even the simplest of them has pro’s and con’s to be considered when implementing them. Like everything else in the programming world, you better have a good reason to do what your doing, because in the long run, you could be stuck with what you do for quite a long time!
So what are Design Patterns?
Any discussion about Design Patterns must include a passing reference to Erich Gamma, Richard Helm, Ralph Johnson and John Vissides. Affectionately known as the Gang of Four, these men authored a book in 1994 that would become the quintessential programmers guide to Design Patterns. The book catalogs 23 patterns, along with the intent and consequences each one brings with it. Since its first publication, there have been MANY advances in the field of design patterns and we now have architectural patterns, enterprise patterns and even “antipatterns” which can be considered patterns we wish not to see in our code.
As I mentioned earlier, Design Patterns are nothing more than common solutions to common problems encountered in Software Development. Each one is just one possible solution to a problem and more often than not, they are interchangeable with at least one other solution. Also, they tend to come in pairs or small groups, meaning more often than not the implementation of one, tends to lead to the implementation of another. Why? Because these patterns tend to work very well together, with one tending to provide the input for another.
Why should I bother using Design Patterns?
There is one HUGE bonus to using Design Patterns – They just work! That doesn’t mean you should rush off and start refactoring your projects this instant. As mentioned a couple of times earlier, Design Patterns tend to bring with them some level of complexity. Some even necessitate a small abstract hierarchy, just to get started. That being said, with that complexity often comes flexibility, extensibility and reusability. These patterns have been used and tested by 1,000’s, if not 1,000,000’s of developer, in various different programming languages and projects. When used correctly, they often allow you to extend your solution to cover more cases, with less effort.
The huge fly in the ointment here, is that often times, a particular problem could be solved with more than one Design Pattern. So how do we decided which one we should use? Unfortunately, the only answer available is a thorough understanding of each of patterns you wish to apply and the consequences of implementing them. Ultimately, it takes a little experience and common sense on your part to make a good decision.
Summary
Since discovering them back in 2005,2006, I realized pretty quickly that Design Patterns could really open up a whole new world for me. I knew they could allow me to solve complex problems quickly using tried and true solutions. However, the one thing that eluded me was not only knowing which pattern to implement, but also when and why.
Recently, I was working on a project for work. During the planning phase of the project, we talked about a few use cases that needed to be covered and quickly realized that we needed a solution that allowed us to change the way we approached the problem at runtime. For those familiar with Design Patterns, this absolutely screamed out Strategy Pattern. Unfortunately, I had never seen it implemented, nor did I truly understand the purpose of the pattern, so initially I struggled to implement the solution. Then one day, the penny suddenly sank and two days later I had a working prototype for the full system.
By implementing the system using the Strategy Pattern, I removed a LOT of complex switch/if/else logic from the code AND had the infrastructure in place to allow me to create a new path of execution with the introduction of a new class and a little configuration. Something that would have been almost impossible before hand.
Design Patterns can provide a gateway to elegant, solutions to even the most complicated of problems. Understanding the intent and consequences of each one will help you make better decisions as to when and why to implement any pattern and when to not bother with them.
Additional Reading
- http://www.softpatterns.com/ – Visual Representations of Design Patterns
- http://www.oodesign.com/ – Implementations in Java
- http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 (Book on Amazon)
Comments
You must log in to post a comment.