Many developers consider the book Design Patterns a classic.
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/07/rethinking-design-patterns.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/07/rethinking-design-patterns.html
Thank you Jeff. Finally someone mentions that the Emperor has no clothes! I have always been floored by the devotion of my otherwise sensible brethren to strict adherence to the GoF commandments. While they force their code into this pattern and that pattern they typically miss the fact that they are more often than not INCREASING complexity rather than following Fowler’s first rule of KISS. Other than that they seem like genuinely intelligent people. Go figure.
I read through Design Patterns once, just to get some ideas for future use. Maybe I’ll refer back to it if someone references it in documentation or conversation, or if I vaguely recall reading something there, but it shouldn’t be used as a hard manual for how to do everything.
Design Patterns are now part of software development Dogma,
any questioning of them will be met with cries of heresy.
Well done Jeff!
I particularly enjoyed /The Timeless Way of Building/ by Alexander. It attempts to describe the concept the QWAN.
http://en.wikipedia.org/wiki/Quality_without_a_name
The concept of QWAN is much more important than a pattern language. A lot of the code that I read that uses design patterns severely lacks QWAN. Code with QWAN can be looked at and you can say, “hey I get how that works” and not require some name for the pattern.
Excellent post =)
I think about this, in the same way I do in some other points
“The OVERUSE is worst thank NO USE it at all”
I hate the overuse of XML, DesignPatters (useless factories, and a lot of things like that), XML configuration, Ajax, and the list go on
Is important to understand and use all these things, but more important is how and where to use them.
The clear example to me is Java vs .NET both use patters but I think that the .NET approach is a lot clever.
In Jave the explicityness of patters (what a word :P) is the key, in .NET you can do simple things with little code or one line, with Jave you need to instanciate a lot of objects, or know about much more clases.
I love “Framework Design Guidelines” from the CLR core team, is an amazing book where patterns are important but be rationale is more 
Best Regards
I agree wholeheartedly. Certainly there are some patterns that are incredibly useful in software engineering, but I find many people focus too much on the usage of a pattern instead of its usefulness. It’s like patterns are many Sr. Developer/Architect’s way of overcompensating for weak OO design skills. Roughly 80% of all pattern usage I see is what I call ‘contrived complexity’. “Oh this uses the Visitor Pattern” the architect confidently chirps. “Yeah, but why? Can’t you just use standard, boring old, solid OO design to do that?”.
What’s worse is that this ‘Pattern Overcompensation’ leaks into the Jr. Developers habits too. I can’t tell you how many times I’ve had a developer on my current project say “we should use a factory pattern here”, when I’m certain they have no idea how empty that statement is.
Who are there architects that I always hear about that blindly apply the Gospel of the Design Patterns instead of thinking? I’ve not seen them, and the GoF book doesn’t seem to advocate it as far as I can tell.
I’ve read Design Patterns more than once, and the only way I’ve ever used them or seen them used is as a verbal/texual/conceptual short-hand for a code technique. “We’ll handle the specific handling there with a stragegy class” or “Well, lets use a factory to keep the object-generation code from mucking things up” or “sort of a flyweight pattern thing to keep these from eating up memory”… just gives a label to things we’ll be doing anyway.
I think of it like music theory. You don’t write a song by cobbling together theoretical rules. However, you can look at a song and think, “Ah, it’s a secondary dominant thing here… I could jazz it a little by substituting…” Also, quite useful when describing to other musicians in a way they’ll understand. You write what you want to write, and use the pre-named patterns for conceptual abstraction, to draw parallels with existing stuff, and to communicate to others.
I’m also quite familiar with the “design patterns are usually a flaw in the language/framework” argument. A valid point. I’d also like to note that I also have to keep wearing shoes because nobody has gotten around to carpeting the sidewalks. I don’t like C++ or Java; they force me to bend backwards to do things that are simple in other languages, but I rarely have the luxury of choosing whatever tools I like on a project I’m getting paid for, so the non-necessity of certain patterns and idioms may be in more modern languages is not that relevant most of the time.
Who are these architects that I always hear about that blindly apply the Gospel of the Design Patterns instead of thinking? I’ve not seen them, and the GoF book doesn’t seem to advocate it as far as I can tell.
Indeed. Ever read “The Bible”, or “The Quran”? Strangely, those books don’t advocate a lot of the things you’ll see people doing in the name of them, either.
You aren’t actually supposed to program with design pattens in mind. You are suppossed to program with the knowledge design patterns gives you and not think in terms of I’m going to use strategy here, or visitor there, that leads to muck. Designing around a particular pattern is an anti-pattern. Design patterns ae discovered from existing code not written down from scratch. It is the knowledge the pattern holds that is important not the pattern itself.
The good thing about design patterns is that they provide a shared vocabulary for some concepts.
The bad thing about a shared vocabulary (not necessarily design patterns, mind you) is that you’re well on your way to providing more evidence for the Sapir-Whorf hypothesis ( http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis ) by knowing them.
There’s a right way and a wrong way to use patterns - if you start to see patterns emerging as you’re building your system, great. If, during the Big Design Up Front, you hand down a mandate from the heavens that “Object Bar will implement the Singleton pattern”, you’re doing it wrong. Put down that Golden Hammer, kind architect.
Form should follow function rather than attempt to inform it.
Jeff - surely this has been suggested to you before, but I strongly recommend you check out Head First Design Patterns. It’s more of a teaching book, whereas the GoF book should really be considered more of a reference. HFDP teaches good OO design principles, and then sort of reinforces them by introducing design patterns as common solutions which follow those principles.
I think the real problem with GoF is how it’s applied. It’s not meant to be an instruction manual. You should already be familiar with OO design and the common problems associated with it before you even start thinking about patterns.
Another problem with GoF is how obtuse it is. HF gives you tangible, if impractical, examples (QuackBehavior on a Mallard which inherits from IDuck, or somesuch) whereas GoF seems to talk about accounts and transactions and other boring stuff that only makes sense to programmers who’ve written accounting software.
I strongly recommend you check out Head First Design Patterns.
It’s linked in the above article, too, but…
As Keebler said, some (IMHO a large measure) of the value of the GoF book, is that it facilitates communication. Two other examples are Martin Fowler’s PoEAA and Refactoring, both of which don’t have much deep metaphysical insight, but do provide a common vocabulary for the things we do. This not only helps communication, but can be valuable to clear one’s own thinking.
Oh wait –
It’s certainly worthwhile for every programmer to read Design Patterns at least once, if only to learn the shared vocabulary of common patterns.
– we seem to agree. Never mind
I subscribe to the idea that for every design pattern there is a language in which you do not need to use that design pattern, because the language allows you to express your intention directly.
However more often than not the choice of programming language is driven by other factors. Sometimes you need to use Java because it is your companies standard. Sometimes you need to use C or C++ because no other language gives you the same amount of control of the machine internals.
In those cases you want to use design patterns to implement those recurring problems that are not directly expressable in this language.
Well, I guess this kind of criticism can be applied to almost any book. If you just blindly follow formulas, you are a chimp developer, and we all know there are too many out there.
As you said answering another comment, any book that becomes canonical (like the Bible, the Koran, Fowler’s EAAP, or even Code Complete) can lead to lots of people blindly following what “looks” like a recipe, and not getting the real message.
You can surely find building architects applying Alexander’s patterns in a literal way, too.
In the end, I agree with you that we -the people presenting and training and writing about stuff- should try to clearly state that Design Patterns are not recipes, but conceptual models to help talk about design. I did many trainings about Design Patterns and I’m a witness that they actually work, but you always find some people thinking about them as templates.
Also this is something where Microsoft didn’t help. While I’m generally fond of Patterns Practices, I feel that some of their guidance is not clear enough and many times it drives people to the patterns=templates…
See you.
Jeff, I just took a class that delved through most of the design patterns in this book and then attempted to put them into practice in different projects. I don’t think we looked into any of the coding examples (honestly, Smalltalk and outdated C++ were not helpful at all), but like you said, it’s the ideas that count.
For students who are learning about the software industry and how to design software systems, this book is an invaluable tool about how some problems could be solved. It’s by no means a “Golden Hammer”…but at the very least it encourages discussion about different methodologies in programming.
I read Notes On The Synthesis Of Form last year because it was shorter and cheaper than A Pattern Language… I would say it’s probably as valuable for time invested, even though some of the ideas are questionable (such as every design constraint simply being a binary value).
Once, a long time ago, I was discussing a movie with my brother and explaining why I thought the symbolism was over the top and unnecessary to put through the screenwriter’s intentions. My brother responded with “You ruin movies. Can’t you just watch a movie without analyzing it?”
The truth is, no, I can no more unlearn to recognize symbols, both conscious and subconscious, than I can lose the ability to see the color red. I can still find a movie funny, sad, sexy, exciting, or terrible based on its own mertis, but I cannot view it superficially.
A Pattern, like a program, is a conglomeration of symbols. Once you learn to recognize them, you get a deeper understanding of the art of writing code. This doesnt mean that you cant appreciate simplicity, or that programming that doesnt comform to a Design pattern doesnt follow a pattern and hasnt been designed. But you cant help but remember what a Strategy pattern is, for instance, and when a problem presents itself that can be solved easily by a strategy pattern, not think to use it.