I have been aware of design patterns since my undergrad days, and learnt about them through a course on software engineering and refactoring which recommended the
gang of four book. Much more recently I have discovered
Christopher Alexander, the originator of the idea of
pattern languages.
Recently a colleague discovered design patterns and embraced them wholeheartedly. Unfortunately the experience was not good. Despite having a lot of experience teaching object-oriented programming and having developed several earlier versions of the software, the entirely new code-base developed around implementations of design patterns quickly became so unwieldy that the new version was abandoned. Every time a new feature was requested it took so long to understand the pattern-ated code that each new iteration took longer and longer to produce. Patterns were however meant to make the code-base simpler to understand and maintain. So what went wrong?
Well to begin with I don't think that design patterns, despite their name, have much of a place in the initial development of software. The software design patterns that we have at the moment should not be used like recipes would be used when cooking. A better way to think of them is as a structured method of describing good design practices within a field of expertise. When you come to a problem, with the intention of developing software that provides a solution to the problem, then that is what you should do.
Write code that solves the problem. If you happen to have produced the best solution to the problem then it should be added to the pattern language for that domain so that you may communicate your solution to others so that they may benefit.
This is as opposed to working out which pattern you should implement in order to solve the problem. Of course if you are working in group then it is important to be able to communicate your solution, it is in this role that design patterns become very useful, as a communication tool for building consensus and understanding. However, if you find that implementing a pattern to solve a problem is adding to the complexity of your code-base then perhaps, either it was not the best solution to the problem or you have not produced the best implementation of that pattern. Perhaps though I have just not been exposed to a methodology that incorporates patterns as design elements or recipes which actually works to produce code of the sort that I like; where the code solves the problem and there is just enough code to solve the problem, and no more.
I think that this is why the term pattern language is more appropriate than the term design pattern. It is better to think of the patterns not as actual elements of a solution but as descriptions of elements of a solution. When we think of them as descriptions of elements, as part of a language for describing things, then the utility of design patterns becomes self-evident. They give us a language for communicating elements of our solutions to others which is a very useful tool to have. However, as evidenced by my colleague, if they are seen as integral to the software design process, if you are always thinking in terms of the patterns that you will implement to provide a solution to your problem, then you are working one step away from the problem, and attempting to solve it as though through a filter or interface rather than wrestling with the problem directly. This is not to say that you cannot develop good software in this manner but that it is adding tools to the process, making it more weighty than it needs to be, and consequently making your code prematurely more complicated.
