Of Design Patterns And ‘Patternitis’
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).