I also regard design patterns as a bad idea, but for a different reason. I regard myself as a mathematician, though I’ve made my living programming before, spent some years as a physicist, and now I’m doing biology. To me, design patterns are a first step, but they’re incredibly incomplete.
When I am faced with a pattern in whatever system I’m studying/crafting/whatever, I pull it out and encode it as a nice, clean mathematical structure. I play with it until a useful decomposition becomes obvious, and in many cases that decomposition is in terms of mathematical structures I consider old friends.
But it goes in the other direction, too. A design pattern is an interpretive dance: you recognize that you are going through this motion again, and the recognition lets you draw on past experience to go through it a little more easily. Instead, I take the mathematical structure I have distilled, and consider it as an element of some class, then seek the natural structure on that class. Many people protest this as too abstract and a waste of time. What they don’t realize is that very often by abstracting as hard as you can, you find a space where the problem is trivial. Then you take your solution just plug in whatever the given case is.
You can do this in any language. Object oriented programming isn’t particularly helpful for it. Functional programming is helpful for exactly two reasons: it maps very easily to how mathematicians think, and functional languages usually make it incredibly easy to define data structures. My two choices would be Haskell, followed by ALGOL68.
Couldn’t have said this better myself! Like many others, I use GoF and other materials as a starting reference point and adapt them to fit the problem at hand.
Oh, and for the guy who thinks you don’t build a bridge from scratch each time – newsflash – you DO! At least if you want it to work. Every bridge is different. The physics of a suspension bridge are GENERALLY the same (which is akin to saying all C# programs are written in C#), this [only] gives you a starting point from which to base your design, but the parameters of the bridge’s location, what it spans, weather, etc. all come into play during the design and implemenation of the bridge.
“Dominus believes that the Gang-of-Four version obstructs Alexander’s message, replacing actual thought and insight with a plodding, mindless, cut-and-paste code generation template mentality”
Anyone who believes that is missing the message in the GoF. They specifically say patterns are not code templates. Admittedly this is a difficult thing to get across to some people.
“Yes, this book full of code that looks exactly like cut and paste code templates? It’s not a book of cut and paste code templates!”
Well, they don’t look like cut and paste templates to me, but then I read the words in between them
I think that is largely the problem - too many people don’t take the time to read what the book actually says (I’ve even met people prepared to argue about what it says, having never read it).
It may not be the easiest book in the world to read, but Dominus is assigning blame in the wrong place. The GoF definitely did not intend their book to be a set of code templates. That point is made over and over again (in the discussion of every pattern, in fact).
It seems like design patterns are great for understanding how to properly solve a particular problem in an application but perhaps if you have the same problem occuring over and over again rather than re-implement the same design pattern it might be a good time to think about implementing a domain specific language.
Has some very interesting comments in the first few chapters. Mostly it’s a manual for using the tools but at least the first 100 pages or so talks about when it is appropriate to use a DSL and the virtues of DSL’s. I found it interesting.
A number of design patterns (for example factory/singleton) have very trivial implementations in a dynamic language such as ruby, and actually lot of patterns are there to fight the static nature of the language.
Why would you need the decorator pattern in ruby, when you can simply add new methods to any object at runtime? (there’s actually no difference between runtime and compile time as the language is interpreted).
This article is the hype that I don’t believe. Far from being irrelevant: although the book is now over a decade old and is still relevant. Overwhelmingly the book has changed many people’s coding style.
1 Unless your system is small then not using patterns is more complex. I cannot understand your first criticism, even fundamentally. If you have people who fail to grasp GoF on the project then they are still getting to grips with OO. Imaging designing a GUI without some form of Observer. You often end up with an unthinkable tangle of code: not much of which you can reuse. There are many other examples.
2 Patterns aren’t supposed to be boiler-plate for one: which is why the community backed off building pattern support directly into lanagages. Varients of patterns are often used or adapted to suit the problem at hand.
As for turning programmers into macro-processors, that’s like saying authors are dictionaries. It’s more of a The whole point about patterns is to allow others to pick up your code. The fact a lot of code looks the same is a good thing as actually may developers aren’t actually as talented as they think they are: they learn by copying and adapting. Which is why GoF is here to stay for the foreseeable future. Comparing patterns to idioms in other languages does not weaken the case for patterns as it’s not the same thing being compared. How an iterator can be compared to a perl foreach loop, or a bit of lisp is nonsense. They are different tools: this is a valed attack on some of the languages where the patterns are most use. Both perl and lisp might allow the programmer to be expressive but hands up who would like to pick up the maintenance? Even so Patterns are not irrelevant in both.
As for architectual patterns, my understanding was that Alexander is mostly read by computer professionals and not architects at all. I’m sure you could equally argue that GoF has far more influence over the software community than Alexander over architecture.
I also have objections to the Design Pattern religion, but for a reason not mentioned here: a complex concept cannot be reduced to a single name that means something to everyone.
For example, what is a “decorator” pattern? Can anyone honestly say that the word “decorator” describes a function you regularly do in programming? In my mind, a decorator is someone that comes in and throws colorful pillows on my couch.
I have bjections to most of the GOF naming convention. The names don’t describe the problem they are attempting to solve, so trying to find a pattern that applies to a particular problem takes way to much time. It is simply impossible to abstract a complex issue to a single word. (Although politicians try mightily to do that.)
I’ve actually had a job interviewer ask me what various patterns do BY NAME. That is how insidious this religion has become. He never asked how I would handle a given programming problem. It was all about having memorized the book.
This objection extends to much of the programming landscape. It seems that everytime some fresh hot programmer (re: wet behind the ears) thinks he or she has written something new (…doubtful) they try to give it a catchy name, or worse, an acronym that is already in use. (I’ve actually seen RAM and DMA used for someone’s pet design!) It is like criptic comments in code. Give it up! Use a multi-word description.
I read Christopher Alexander’s “A Pattern Language” book within weeks of it’s publication because I though it might describe the kind of “patterns” I was using to design software at that time… I enjoyed it. I liked the way the patterns fitted togerher and the discussion of the forces that the patterns try to resolve.
But I thought that some of the architectural patterns were unworkable… and that it had no application in computing.
Wait. We’re supposed to actually use design patterns? I thought they were just terms you use at design meetings to sound impressive in front of your boss, e.g. he says, ‘functionality XYZ is essential to this project. Do we know how to handle it?’ And without looking at the requirements you reply, ‘Sure, a combination of the strategy pattern and the singleton should take care of it.’
Design patterns are also a good way to haze people you don’t want to hire during job interviews, so you can go back to your boss and say, 'boss, your nephew seems like a great guy but he isn’t quite up to snuff when it comes to design patterns.
So now you’re telling me that all along we were also supposed to be using these design patterns in our coding? What’s next, actually pairing up to do extreme programming?
I’ve seen more garbage written in the name of some design pattern than anything else so when someone I work with says the words design pattern my hair just stands on end.
It’s been said GoF is mostly a band-aid for C++ to make up for features standard in functional languages. E.g. Peter Norvig argued in 1998 70% of the GoF patterns are superfluous in Lisp. I suggest the same applies now to JavaScript and Ruby and that the other 30% were nonsense right from the start anyway (see e.g. Interpreter).
"If you know beforehand to what extent your application or library will grow, then you should consider more of a rapid development approach, if you don’t, put in the extra effort.
CptBongue on July 6, 2007 06:15 AM"
I think you’ve identified a key issue. Many of the patterns carry with them the implicit assumption that the design will change. The choice of pattern is often based on how or where that change will occur.
The more subtle assumption is that it will be more effective (cheaper, faster, better) to design the architecture to anticipate the change (or at least its type).
In practice, change is not inevitable, the type of change is not always predictable (even at the 10,000 foot level), and sometimes it is more effective to wait for the change to come before dealing with it.
The best choice will depend on the entire context of the project including operating environment, programming language, staff, requirements, market, budget, maturity of the company etc.
For example, my experience in start-ups suggests that any work that you can put off for a year or two will increase significantly your chances of survival. Sometimes it’s literally true that there isn’t time to do it “right” but there may be time to do it over.
Saying that Design Patterns are only part of a larger concept of patterns misses the essential point of how GoF design patterns were developed specifically and the large number of OOP concepts they clarified. The value of the GoF work is that it clarifies OOP, and while OOP is certainly not the be-all and end-all of programming (ask any FORTH programmer), it has been a great aid in moving the whole discipline of programming ahead. By the same token, design patterns move it even further.
To say that one needs to go to the “source” of design patterns to really understand why GoF is talking about does not ressonate. It’s like saying that one needs to learn Latin and French to really understand English. Nothing wrong with that, but it’s really not necessary.
I do not think that the GoF had the same agenda as Alexander; Alexander seems to have wanted to push the idea of distributed responsibility; the GoF seem to have had a set of generic solutions to software problems and a good way of documenting them for comparison and clarity. The GoF left the project management side out because they’d have been on a hiding to nowhere with all of the existing software project management mumbo-jumbo. Whereas the construction/architecture sector has stuck with the same management method forever, which Alexander was trying to change. So Alexander’s book covers two subjects: how to manage projects, and design patterns for ‘consistency and harmony of overall design’; the GoF book only covers the latter because they assume that either you are an experienced enough developer/project manager to understand project management, or that you’ll seek your project methodology from other sources.
The GoF never presented their book or design patterns in general as cookie-cutter templates; they presented them as potential solutions, and provided hints and examples so that developers could learn to identify a problem space that one of the design patterns could fit rather than having to reinvent the wheel. The patterns aren’t presented as dogma or a replacement for good design, they are presented as aids to conceptualisation, analysis, and design.
If developers have been lazy enough to read the book without thinking about what the patterns are or even reading the introduction, or are too dense to understand, they should be relegated to junior positions under the mentorship of developers not afraid to use their brains.
Regarding your first issue:
Design patterns aren’t a recipe, but a language. If your system is too complex, it’s the designer’s fault, not the fault of the language the designer used.
The problem space defines the complexity required for a solution. Language does not add to this complexity, but lack of language may - particularly if used by an inexperienced or clumsy designer.
Regarding your second issue:
The premise “bad engineering = rewriting boilerplate” is a statement in and of itself and completely accurate. The follow-up comment about broken language is disjoint and nonsensical.
It’s well established that some problems are more easily described with some constructs of some languages. The concept of telescoping languages transcends “your language sucks” arguments. If your language doesn’t support your desired functionality, build it or find an existing solution. This is why a thriving developer community is one of the most important aspects in selecting a language - whether you’re choosing a programming language, or a system design language.
The problem with design patterns is that the people that think they are most interesting are people to whom they are original concepts (crap coders) and it becomes a tool for them to cover their junk code tracks. This is the true legacy of code design patterns; despite the advantages of a ‘common language’ most of the time you end up using the common language to explain just how bad a mess someone has made.
And b) there is nothing great about Alexanders book. Just because it has a real architecture connection doesn’t give it any special legitimacy.
I guess I’m lucky in that I never got exposed to the dogma in question. I know about the design patterns and I do use them on occasion, but even back in university (which was engineering, not CS, by the way) I’d learned that these patterns were um, patterns. Not rules.
Sometimes a polymorphic design with a factory class can save me a lot of headaches (emphasis on the “some” - I can recall exactly four instances over more than 15 projects). And iterators are nice, although they’re kind of baked into the C# language by now.
So I agree with the post, I suppose, but the problem it’s referring to is just alien to me. I simply haven’t encountered this strict adherence to design patterns, in my work or earlier formal education. Is it really so widespread?
I feel patterns are best used to recognize what I am doing and how it may interact with other things, rather than a way to make code.
Also, I have a hard time believing that they have considered every problem possible. I therefore think that the solution needs to fit the problem, and this may or may not fit a pattern.
Like many others, I use GoF and other materials as a starting reference point and adapt them to fit the problem at hand.