The perils of avoiding heresy (or "What are Design Patterns?")
etymon.blogspot.com/2006/04/perils-of-avoidin...Posted Jan 3, 2007, 12:59 AM UTC
3814
etymon.blogspot.com
Why have programmers settled for mediocrity? I can understand a book which documents kludges for a given tool, but isn't the root of the problem the tool itself?
3
I thought the point with singleton was that you don't have to worry whether a potentially expensive object has been created already - if it has, you get it, if not, it gets made, and you don't have to know the difference, or check anything. If you have a truly global variable, you also need a wrapper function around it to emulate this behaviour, and even then, the variable wouldn't be encapsulated (and so, not protected from random messing about)
Heresy? Hardly. It's quite popular in certain communities (cough, reddit, cough) to dismiss design patterns.
("Comments are restricted to team members")
2
Banging on Singleton for being a "global variable" is a cheap shot. A lot of poor programmers abuse the Singleton implementation to get that effect, but that's not primarily what Singleton is for. That said, it is a very dodgy pattern: the motivations given in GoF are weak. For instance "there should be only one file system and one window manager." Why? Rather than assumptions about the deployment environment it would be much more interesting to talk about user's domain concepts that only admit one instance. Doubly unfortunate that the Singleton writeup in GoF does talk about global visibility. There are also implementation reasons to use a Singleton, I'd expect, to refer to another GoF pattern, that Flyweight objects (Muys misses another sucker punch there: Flyweights are "just" symbols, right?) would be Singletons.
Muys' critique of the other patterns isn't that great either, not showing much evidence of really deep understanding of what they're about. But deep understanding really isn't what his posting is about. No, it's about condecension. His motivation is made clear by this comment:
So if the book is predominately a catalogue of unfortunately necessary kludges around the semantic weaknesses of mainstream OO-languages, why do I still highly recommend it to new programmers?
Well for starters, precisely because it is a catalogue of necessary kludges. The book does capture (with the exception of Singleton) good work arounds for the weaknesses a programmer is going to face when working with C++/Java/C# (and to a lesser extent Python/Ruby/Smalltalk/etc). We all find ourselves needing to work in these languages from time to time, and it is well worth knowing cleaner kludges.
I recommend that programmers should read GoF too, but not so much for the patterns themselves as solutions, but for the arguments about OO design encoded in each write-up.
6
No, it's about condecension.
No! Could it be that language advocates could be condecending?
cough blub cough
3
I'm afraid so. It's just not usually so blatant.
In other news: world is round, Pope is Catholic
2
To the author of the blog post:
If you're referring to the GoF book, you're wrong about all your C++ statements - the examples in the book is written in Smalltalk.
This clearly states that you have no idea of what you're talking about...
-2†
My copy of the book is 30th Printing September 2004, so I can only speak to that version, but the examples are primarily C++.
5
Here is good debunking of GoF book: Design Patterns in Dynamic Programming
Basically most patterns in GoF-book are workarounds that make non dynamic around the restrictions that the implementation language has. In dynamic languages many of these patterns are no use (like visitor pattern).
-6
Thanks for the link. It's a really good presentation.
It doesn't debunk GoF though it essentially reiterates kawa's post above. Patterns aren't a dogma, they're solutions to problems someone thought worth telling in the context of particular language features.
3
While the author clearly has no idea what he's speaking about it a sad fact of life that the mistake he makes is rather common. Patterns are not, were not and were never 'invented' to be 'design rules'!
It was the total opposite: The GoF Book was created to identify and to name common patterns which are used by programmers since long ago. Not a single pattern was invented by the authors, they only invented the NAMES!
The book simply is 'Computeronomy' - analog to 'Astronomy' which got its ending 'nomy' from the word 'nomen' which means 'name'. In the beginning Astronomy simply named stars, created star maps, identified patterns in the movements of 'stars' etc. Thats the same the GoF tried with the pattern book: Identify and name common patterns in programming.
Later this seem to be forgotten and now many people really think that they should use those patterns. While sometimes this is a good idea, it's not because the GoF said so, it's because those patterns where used and discovered by lots of developers simultaneously which indicate that they are kind of useful.
But it's no requirement. It's simply a help to prevent people reinventing the wheel again and again. And also to make it more easy to speak about a certain program: Instead of describing again and again the use of a certain pattern (which isn't even identified as pattern by the developer), he simply say something like "I use the observer pattern here". So the pattern names simplify the communications between developers who talk about a projects.
Every language uses patterns. Lisp uses patterns, Haskell uses patterns, your soon-to-be-invented language uses patterns. But of course they use other kinds of patterns. But the GoF book was written with OOP in mind so they identified and named OOP patterns. Everybody who talks about "debunking patterns" or "heresy" if he uses other patterns simply has no clue, what the book was all about.
If you use other patterns in your daily programming practice: Fine! Use them instead of the GoF patterns. And write a book or at least a blog post about them, because this could really be interesting.
But bitching about how useless those patterns are and how clever you are, that you discovered (duh!) that certain patterns can do more harm than good if used in the wrong context only makes you look stupid to developers who know their stuff.
I have often seen the GoF patterns preached as if they were papal law, with little or no discussion allowed as to their merits or even when they should be used. Meanwhile other, and arguably more suitable, patterns are neglected.
Design patterns, as a concept, are a good thing. But the reverence academia has placed on the GoF patterns have caused quite a bit of harm. For a decade our schools have been churning out new programmers who know the GoF patterns by heart, but have no idea how to write the simple code that doesn't need them.
Thus any work that shows that alternatives exist or that the patterns are not applicable to all languages is beneficial in my eyes.
Not if you work on a project with me, please. A common language is far more valuable than a "powerful" language.
So you would rather use a GoF pattern with a name than a better pattern without an 'official' name? Can't imagine this. I use other patterns which are not in the GoF book too, general ones like 'lazy initialization' or 'cache' and more special ones in the context of certain libs.
Simply set up a meeting, present the pattern and the name and you've extended your language which is then not only more "powerful" (but I would prefer the word "comprehensive" instead) but also common again.
Use the concept of patterns: Identify them, name them and then you have a richer language to talk about a project.
People who only rely on those 'official' patterns simply don't "got it": The book was about the idea of naming and identifying patterns and to show the validity of this idea they also presented some patterns they discovered as often used in OOP.
But it was never the intent of the authors to force programmers to use those (and only those) patterns they described in the book. They only provided a starting point.
In the 15 years or so since GoF came out there have been many, many other patterns identified, named, written up and published. None of the other collections of patterns seem to have quite caught the imagination of the programming world at large the way that GoF did, but there's plenty of them.
Every programming shop of any size nad longevity will have its own patterns other than those in GoF but the programmers might not realise this. They will be helped locally by capturing, recording and making explicit those patterns that they are using. And then lots of other people will be helped globally by publishing those patterns. Writers' Workshops at the various PLoP conferences can help with this. PLoPs are a bit weird, definately not your average technical conference, but the process does work and a lot of good stuff is available through the proceedings.