WARNING: Below contains strong opinions that you may not agree with! Read at your own risk…(and if you disagree, tell me why I’m wrong in the comments! I have an open mind 🙂 )
In my last post I wrote about 12 Influential Books Every Software Engineer Should Read. I hope most people found it helpful and would love to hear about any other books you would like to have added to the list. There was one book, however, that received more controversy than rest. This book was “Design Patterns: Elements of Reusable Object-Oriented Software”.
Some people who read the post believed that knowing design patterns was not a fundamental or crucial skill to being a good software engineer or programmer. Others believed it was more important than all of the rest of the books and were mad that I had listed the book as “Number 10” instead of “Number 1”.
In this post I’ll give my 2 cents about design patterns and I’m sure just as many people will disagree with me about the thoughts I have on the subject. (I’m okay with that)
Lets first define what we are actually talking about because there are lots of definitions of design patterns on internet but Christopher Alexander (who is a famous architect noted for his theories about design) says, “Each pattern describes a problem which 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 in the same way twice”
In simplest way “A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design“.
In general, a pattern has four essencial elements:
- Pattern Name
- Problem
- Solution
- Consequences
Patterns in the software community seem to be all over the place. There are patterns for everything it seems. The book “Design Patterns”, that I wrote about in my previous post, is 400 pages and doesn’t cover nearly all of them. So how do you know when and where to use a pattern and how much stock do you put into this? Am I not a good developer if I don’t understand and use all of the patterns? Am I a great one if I do?
Design patterns are both praised and criticized in the development community. My own perspective has changed throughout the years. I strongly believe that knowledge of design patterns is required. Just as we learn algorithms we should study design patterns to understand how potential problems could potentially be solved.
But that is where we need to stop.
Blindly pushing patterns into the code will increase complexity, introduce bugs, and create a maintainability nightmare. Instead, we should understand the underlying principles and ideas to apply them or build upon them as needed. As Jeff Atwood, author of “The Coding Horror” technical blog and the co-founder of the popular site stackoverflow.com, says:
“Design Pattern are a form of complexity. As with all complexity, I would rather see developers focus on simpler solutions before going to a complex recipe of design patterns.”
If you find yourself frequently writing a bunch of boiler plate design pattern code to deal with a reoccurring design problem, that’s not good engineering, its a sign that your language is fundamentally broken.
The author of “Higher-Order Perl”, Mark Dominus, also believes that the patterns obstruct the ideas of Christopher Alexander and others. In his article about design patterns, he points out that although the movement was inspired by the pattern language work of Christopher Alexander, it isn’t much like anything Alexander suggested. In fact, what Alexander did suggest is more interesting and would probably be more useful for programmers than what the design patterns movement chose to take.
He makes the same point that Jeff Atwood makes, in that the patterns that are used recurrently in one language may be invisible or trivial in another, and that many patterns aren’t really addressing reoccurring design problems in object oriented programs, they are actually addressing deficiencies in object oriented program languages. He makes the point that instead of seeing the use of design patterns as valuable in itself, it should be widely recognized that each design patterns is failure of the source language.
I personally see the truth somewhere in the middle. As programming languages evolve, we will see more and more languages with built in patterns. At the same time, more and more patterns will emerge as the new problem spaces develop. The cycle will continue and for a person to be a well rounded developer or architect it would be necessary to learn and understand modern and classical patterns. It is also crucially important to understand patterns even if they are natively built into languages. An example is IEnumerable in C#: Without a clear understanding of the Iterator Pattern and its implementation in C#, developers often make costly assumptions. In many cases such code was indeed the performance bottleneck for the entire application. The Microsoft® .NET Framework base class library (BCL) already makes extensive use of patterns, and you are probably familiar with the most common ones, even though you might not realize it yet.
I think a good thing to keep in mind, especially for someone just learning design patterns, is that a pattern is a state of mind, mostly. Don’t ever try to force your code into a specific pattern, rather notice which patterns start to crystalise out of your code and help them along a bit.
Deciding “ok, I’m going to write a program that does X using pattern Y” is a recipe for disaster. It might work for hello world class programs fit for demonstrating the code constructs for patterns, but not much more.
I hope you enjoyed this post and if you think this is completely absurd then let me know in the comments! (or if you liked it that would be nice too haha)
Leave a Reply