The concept of using design patterns to solve problems in software development is by no means a new one. The Innovations of Christopher Alexander in the 1960’s and 1970’s in the area of design created a spark in the world of software engineering, particularly his 1977 book A Pattern Language. The 1994 book Design Patterns: Elements of Reusable Object Oriented Software by Erich Gamma et al (widely referred to as the GoF or Gang of Four) further ignited that spark and was arguably the most important catalyst in the design pattern movement. Since then, many books have been published on the topic and other patterns which were not included in the GoF book have been elucidated. They have been used in just about every programming language which provides support for object-oriented programming.
But what really are design patterns? According to Christopher Alexander himself:
Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
In other words, in the context of software design, design patterns are simply tried, tested and proven solutions to common problems encountered in software development. In PHP, the primary language that I use nowadays, these patterns are prevalent. Some of them are now so commonplace that it seems as if they are a part of the language itself. Even their names integrate smoothly with the developer lingo. Developers now speak of ‘using singletons being akin to using global variables’ and ‘building prototypes and factories to generate objects’.
Some design patterns over time have proven to be very useful in the development of robust applications, others have been found to create more problems than they solve. However the biggest problem to date with design patterns is not inherent in the patterns themselves but is more a function of their enormous popularity in the world of software development. Design patterns, due to their ubiquity, have been misused, overused and abused to no end. Many developers today seem to have lost sight of the original definition of what a design pattern truly is. If we refer to the words of Mr. Alexander, we come across perhaps the most poignant aspect of design patterns: they define the core of a solution to a problem. By that reasoning, if a particular problem doesn’t exist then the corresponding design pattern should lose relevance.
I have reviewed many a source code where its seems as if a ‘problem’ was invented solely to facilitate the use of a particular pattern. The developer of this code proudly thumps his chest proclaiming that he has used ‘x’ pattern or ‘y’ pattern in his application and as such it is the epitome of quality. Of course, the problem here is that the developer has allowed these design patterns to define his code rather than let the problem his code is trying to solve define his code and by extension any patterns used. This problem of developers blindly attempting to fit design patterns into code where it is neither required nor desirable is one for which we unfortunately have no design pattern.
To compound the issue, there are those instances where developers encounter a legitimate problem which calls for the use of a documented design pattern and they attempt to use a ‘cut and paste’ method of applying that pattern. Referring again to the definition tabled by Mr. Alexander, design patterns define the core of a solution. Not the entire solution outfitted with all the bells and whistles, just the core. In a sense then, a design pattern is a concept. You simply cannot cut and paste a concept. If you attempt to do so you are doomed to epic fail. Design patterns are meant to be understood and applied with a certain degree of innovation, tailored to suit the parameters of the environment in which they are being used.
Design patterns are at their most fundamental, ideas. Ideas can be tweaked, added to or thrown out for other ideas. They should never be used where they violate the KISS principle and they should not be idolized. There are always alternatives. Always bear in mind that a design pattern should only be used in situations where it is the best applicable solution and should never define your entire application unless of course it is an architectural pattern (such as MVC).
Short URL for this post:
http://bit.ly/OWzbI
Liked this post? Disliked it? Let people know! Share it!
J from Montana, United States on 
Stephen Orr from Walsall, United Kingdom
Corve from Saint Andrew, Jamaica
{ 2 trackbacks }
{ 6 comments… read them below or add one }
You so learn some Java programming, the entire language is the abuse of a design pattern.
MVC is also a design pattern, irregardless of what that wiki articles says because anything that has any effect on the way code (especially on a global level such as a MVC) can’t be considered as just “architecture”.
I think its a matter of lack of expirence and ignoring base patterns.
Twitter: @SamuelFolkes
Owen,
Architectural patterns aren’t really an ‘architectures’ in the technical sense of the word. They are more like application blueprints. MVC certainly is a design pattern but it falls in a specific category. Design patterns are split and defined by different types (creational, behavorial etc.). Hey your link is down right now. I was looking at your work with the pascal GUI the other day from back in ‘03. Thats some heavy stuff man, lol!
Even if it falls into a different category I still like to call a chicken a chicken. yeah my web host server has a mind of its own. that pascal stuff is light years ago, i keep saying i;m going to pick it up again and finish it but web dev has made me lazy.
I’ve equated design patterns to data structures. Data Structures are tools and techniques to manage data in a procedural language using allocated memory and pointers. Design Patterns are tools and techniques to manage behaviors in an object oriented language using inheritance, aggregation, polymorphism, static invocation, etc.
Design patterns are like recipes. They describe how to make something. The first time or two you use one, you should probably follow the recipe closely, but as you become more familiar with the pattern, and you understand how and why to use it, you can tweak the pattern recipe to match the problem you’re trying to solve.
Now, i try to study about design pattern and found this post.
Thanks for sharing, still reading it, although it’s very difficult to understand because i am guessing it’s an advance technique.
Twitter: @weierophinney
There are two primary reasons to use and study design patterns. The first is to help you identify solutions to problems. Often, when trying to understand how to code a solution, you’ll realize that the problem looks like such-and-such pattern, and this provides you with a path towards implementation. The second reason is that patterns give you and the developers you work with a shared vocabulary. As an example, a co-worker may ask you how a specific piece of code works; instead of going into tons of detail, you can simply say, “it’s an implementation of so-and-so pattern,” and they can immediately grasp how the internals work. These two reasons alone are reasons to know design patterns.
That said, you hit the nail on the head in your last paragraph: “Design patterns are at their most fundamental, ideas. Ideas can be tweaked, added to or thrown out for other ideas.” Design patterns do not typically provide solutions, but merely an algorithm for implementation; it’s up to you, as a developer to determine how to do it, and how much of the algorithm to use. I have often combined patterns when developing, or considered a particular pattern only to throw it out in the end as it was too cumbersome. None of these situations, however, make design patterns any less relevant or useful to me; they are simply another tool in my developer tool belt.