Slashdot Mirror
'Design Patterns' Receives ACM SIGPLAN Award
bth writes "ACM's Special Interest Group on Programming Languages (SIGPLAN) recently awarded the 2005 Programming Languages Achievement Award to Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known as the 'Gang of Four') for their creation of 'Design Patterns' (the computer science book and the subfield at the intersection of programming languages and software engineering). The annual award recognizes an individual (or individuals) who has (have) made a significant and lasting contribution to the field of programming languages."
I've worked with a couple of folks who swore by this book, but I never really heard much from them about why. Is it about good algorithms? Or larger design issues (such as)?
Or is it more about just giving programmers a common vocabulary with which to discuss the way they bulid software?
Is it good reading for an amatuer programmer, or more as an advanced topic?
This site is one of the best.
hilarious
Congratulations to the GoF. Their observations of patterns of systems and behavior are well-described and well-cataloged in their book. I only wish the concepts and materials were conveyed better when taught.
Most of the time people start with the attitude "Let's start with the Visitor pattern" or something like that. The point of the patterns movement is there are common things that are done, wouldn't it be nice if we could talk about them with common terminology and use the full richness of our experience to ensure when we see the problem again that we don't make all the same mistakes we made last time.
I'd like to see it taught (and this can be in the programming shop, too) like this: "What are we trying to do? Where have we done something like this before? Doesn't this look like something we've done last month? Can you detect a pattern to all this?!"
Instead, what I often see if people spouting pattern names like one would name-drop at a party--the more you drop the more important you must be. Starting with the problem to be solved, the understanding of same, and then recognizing that we've seen this before, then naming the pattern is less flashy but is more the intent of the GoF IMHO.
Of course it isn't Computer Science, it is Software Engineering. The book helps you design software systems. Can Karnaugh maps do that?
I find it useful with what I work on. If you don't then, maybe the book just isn't for your line of work.
Design patterns are a tool, not a silver bullet. Get what you can out of them but don't be surprised when doesn't solve all the problems in the world.
The patterns themselves are not really that
... }
...
groundbreaking, IMO; the genius of the book
is the perspective on looking at software
as pattern definitions and then their use
in different ways and places in software.
The part that every OO developer should
ingrain in their brain is to
Prefer composition to inheritance.
Good Lord, people love their inheritance
when there are very, very rare situations
that call for it. (Composition, btw, is
where a data structure is used as a data
member of the class).
What it recommends is that instead of this:
class cElement : cParent {
use this:
class cElement {
cParent mParent;
}
Inheritance is so friggin abused by OO
developers, it is ridiculous.
So, my recommendation is to read the first
50 pages or so, which is their general
perspective on programming. After that,
it's just details about the patterns they
have encountered in their careers.
Peace & Blessings,
bmac
"Some is good, more is better, and too much is just about right."
- This mantra is good for money, horsepower, disk space, but not design patterns...
When somebody starts telling me that they used 5 different patterns in their program and they're proud of it - then I know the code is crap. Most of the pattern zealots I've seen write bloated, inefficient code. Sometimes I think they scour the literature looking for some extra patterns to put in.
That said, these patterns do exist and programmers keep reinventing them. The key is knowing when to call it a pattern and go to the trouble of formalizing it versus just writing code. Alternatively, find a language that makes most of these go away.
The classic Design Patterns book is great, and the GOF certainly deserves this award. Still, the book is hard to read. And in daily practice, it's not always clear when to apply which pattern (especially for the less experienced).
I'm reading Head First Design Patterns, published by O'Reilly, right now. It's an fun and easy to read Design Patterns course, which is difficult to put down once you started it. The authors have a great sense of humour, and use a very practice-oriented approach. They tackle day-to-day problems by starting with the obvious solution an inexperienced programmer would use. Then they point out the problems with this solution, and step by step they work to the appropriate design pattern. Patterns are examined from different viewpoints, and the authors try to answer all the questions you might have.
I really recommend this book. In fact, I recommend the whole "Head First" series (I also own Head First EJB). These books are not usable as reference works, but they are wonderful for learning and mastering a subject.
Patterns themselves are good to have in code, but the idea that they must be reimplemented for each case (as opposed to being packaged up into a concrete, first-class language object) really shows the limitations of mainstream languages. Peter Norvig (formerly at Harlequin, and now at Google) did a good writeup of the issue. Paul Graham also has an interesting take on this subject.
A deep unwavering belief is a sure sign you're missing something...
Yes, language bigots always think THEY ARE language is perfect.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
You're right, design patterns aren't duplicated code. They're duplicated patterns of code. Nearly all languages have a tool for handling duplicated code (functions), but few have tools to handle duplicated patterns of code. Lisp macros, however, do allow you to codify patterns in code.
...)" and expands it to an iteration using Lisp's native 'do' loop. Now, that's just scratching the surface of macros. Since macros are just functions, you can do anything with them, including writing a language on top of Lisp. This might seem like a bit of a strange idea, but domain-specific languages are hardly a new concept (ie: SQL), and its easier to build them on top of a mature platform instead of writing your own compiler.
Lisp macros and C macros share only a name. The C preprocessor is just a simple text-substitution mechanism. In comparison, Lisp macros are functions that take source code as input, and return source code as output. They have all the generality of regular functions, except the compiler invokes them at compile-time to expand calls.
The simplest examples of Lisp macros are defining new control structures. For example, Lisp has no direct equivalent of Python's "for elt in container" syntax. However, it's easy to write a macro that takes the statement (for (x in list)
With regards to macros and patterns, an easy way to think about things is to realize that functions are useful when you need to apply the same code to different data, while macros are useful when you need to apply the same structure to different code. The classical idea is that you can't package up design patterns into a library. That's because few languages have macros (ie: functions that operate on source code). When you have such a feature, packaging up design patterns becomes easy. Just codify the invariant parts into the macro, and put the parts of the code that change as parameters to the macro. If you've read Alexanderescu's book "Modern C++ Design", you'll see that this is precisely what he does with C++ templates (which are a limited and kludgy form of macros). This is big news in the C++ world, for the simple reason that it makes code less tedious to write and less error prone.
A deep unwavering belief is a sure sign you're missing something...