'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."

Comments

terminology, methods, what?

[Rubel]

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?

Re:terminology, methods, what?

[fermion]

I think it is about idioms. There are standard ways to copy, iterate, and count. These standard not only make the code more readable, but also provides time tested methods to make the code reliable. Also using these idioms when writing code speeds up the process. There was a time when I could at sketch out a solution to a moderately complex problem in a day, flesh it out in another day or two, and then spend the rest of the time debugging and clarifying.

When we moved to OOP, new idioms were needed. We kept many of the old ones, and the OOP made complying with some rules, such as the separation of data, presentations, and manipulation, simpler. This is what design patterns does. It provides a set of idioms that can be applied to classes of problems. Once these are learned, one should be able to quickly develop a robust solution.

Take for example the singlet. It is a simple construct used when only one instance of an object is allowed. This happens more than one might imagine. I could sit down and think hard for a while and implement singlet, and then redesign, and debug, and after months of work come up with a good solution. Or I could just use the design pattern and in 20 minutes implement my singlet class.

The second part of you question is more complex. I, like most programmer, created crude versions of the design patterns on my own before reading this book. I even saw I enforced some OO concepts on my structured programming. Once I read the book I quickly saw the uefulness and began to use the patterns in my professional work. OTOH, when I was coding some math stuff over the summer, I did not use the patterns because the work was not so suited to the patterns. If i were to publish the work, I might go back and rework to fit the idiom. OTOH I know that the book is used widely and knowing the basics are useful. So if you are coding for fun, it might not help that much. If you are coding to show others, it would help to put the code in a form people will recognize.

Re:As mentioned by Paul Graham

[whatthef*ck]

As mentioned by Paul Graham, in his essay "Revenge of the Nerds", Peter Norvig found that 16 of the 23 patterns in Design Patterns were "invisible or simpler" in Lisp.

If I could make a decent living coding in Lisp, I might actually give a shit.

Oh dear...

[groman]

Oh my

The quite possibly most useless book in the history of computer science gets an award. Somehow I am not that surprised, considering that everybody hails it as the end all of object oriented design and everything.

To be honest, modern computer science curriculum seems to be wasting a lot of bright young potential on buzzwords. Patterns, paradigms, bleh. People somehow manage to get masters degrees in CS from Berkeley without even knowing what "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis" are. But you ask them about a singleton, model-view controller or Java's security model in reflection and they're the fucking expert.

Well that's barely computer science, that's just OO banging. Just because it uses paradigms and object oriented terms doesn't make it anything other than advanced code banging.

Re:Oh dear...

[Anonymous Coward]

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.

Re:Oh dear...

[TheGavster]

As a computer science major, I find it depressing that I only know what half those words mean, and I learned them all in electrical engineering courses. We really need to get back to "Computer Science is highly organized math" rather than "Computer Science is objects".

Re:Oh dear...

[aftk2]

Computer science curriculum seems to be wasting a lot of bright young potential on buzzwords. Patterns, paradigms, bleh. People somehow manage to get masters degrees in CS from Berkeley without even knowing what "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis" are. But you ask them about a singleton, model-view controller or Java's security model in reflection and they're the fucking expert.

Interesting - that you decry the popularity of "buzzwords" with a list of what are, essentially, buzzwords.

*ducks*

Re:Oh dear...

[cratermoon]

People with CS degrees seem to get jobs writing software for money without knowing a thing about security, testing, defect discovery and removal, team organization, refactoring, design, technical writing, communication, estimating, abstractions and complexity management, business practices, communicating with users... well, anything needed to actually deliver working software that delivers value to the business.

But, you know, in case that trucking company struggling with logistics needs to know about "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis", they're golden.

Re:Oh dear...

[patternjuggler]

Computer science curriculum seems to be wasting a lot of bright young potential on buzzwords. Patterns, paradigms, bleh. People somehow manage to get masters degrees in CS from Berkeley without even knowing what "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis" are. But you ask them about a singleton, model-view controller or Java's security model in reflection and they're the fucking expert.

Interesting - that you decry the popularity of "buzzwords" with a list of what are, essentially, buzzwords.


A buzzword is a fashionable word for something either very simple, or something very vague and un-concrete. It makes you sound a little smarter initially, because the word is more intelligent and exotic sounding than 'thing' or 'stuff' (or whatever). After everyone starts using it more and more frequently in contradictory or meaningless ways, then it becomes a recognized buzzword and makes you sound less educated for saying it.

I rarely hear theorems used as buzzwords, though there are instances when a science popularizer tries to explain a theorem in a mass-market medium and then everybody who read the back cover of the book or caught 5-minutes of the show on PBS will start using it.

I've never heard Karnaugh Map used by anybody who didn't know what it meant, people discussing design patterns typically have read parts of the book but are most likely applying the pattern where it doesn't belong, and if I ever heard someone use the term paradigm seriously in a technical discussion I'd probably laugh in their face.

Re:Oh dear...

[SirSlud]

Face it; software is now a commodity business. Using an automotive analogy, if you want to improve the performance or design of the internal combustion engine, go for it, but most software jobs these days only requires putting a kit together rather than having to push the envelope of science.

Therefore, sure, Computer Science is science, but understand that its pure semantics. Its good that enrollment in CS is down, because most of the CS students during the boom were more interested in engineering (applying known scientific discoveries) than the science itself.

The fact that employers looking for programmers ask for CS degrees is simply an indication that the industry is still fairly young. Software engineers used to come out of CS, but that trend is rightfully dwindling. Most programmers really should be trained in an engineering course, where the focus on economics and social responsibility are more pronounced.

Re:Oh dear...

[Anthony Liguori]

People somehow manage to get masters degrees in CS from Berkeley without even knowing what "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis" are.

You're obviously trying to come off as pompus but seriously, do you even really know what you're talking about? What's so important about Karnaugh maps? It's a silly way as solving a system of boolean alegbra equations. Only really useful for introduction digital circuit design.

If you want to talk about boolean logic, talk about predicate calculus, modus ponus, or something that actually deals with Computer Science theory.

I understand where you're coming from and don't fully disagree but you sound like an ass. There's always someone with a more theoritical background than you so just don't do that.

FWIW, the GoF are important because they were the *first* to do what they did--give programmers a common vocabularily to describe complex systems.

An observation...

[bunyip]

"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.

Re:An observation...

[arethuza]

Here is one pattern anti pattern that can increase the complexity of a project hugely. For each class:

• Define an interface for the class to implement
• Create a factory class that does nothing but call the constructor on the class
• Define an abstract factory interface
• Have a factory factory that creates instances of the factory based on a system property or properties file

And do this for every class in your system!

Design patterns are a great idea but they can lead to a huge increase in complexity when people feel that they have to blindly apply patterns for no actual benefit.

Re:As mentioned by Paul Graham

[Brandybuck]

Of course :-)

Language bigots always think they're language is perfect. They even seek out its imperfections just so they can figure out how to recast them as perfections instead. Language bigots are among the most prickly people. Even moreso than editor or OS bigots. Prick them and they explode.

Lisp is a great language, but it's not suitable for most mainstream programming tasks. Sorry, but it's not.

Re:worth it for one reason

[Brandybuck]

Unless of course, cElement is a cParent. In that case inheritance makes sense.

Using composition for everything is just as bad as using inheritance for everything. That inheritance seems to be your pet peeve, makes me think that you use composition much more than you should. Everything has its balance, but when you go out on a limb to tell someone else that he's unbalanced, make sure that limb doesn't break.

Re:As mentioned by Paul Graham

[be-fan]

What's your reasoning behind the assertion that Lisp isn't suitable for most "mainstream programming tasks". Just saying it doesn't make it true.

I don't think any real Lisp user will tell you that Lisp is perfect. There is a litany of complaints your average Lisp user has about the language (even Paul Graham). However, most will tell you that its definitely better than what exists in the mainstream. Lisp users are kind of like Linux users in that way, actually. Feature for feature, mainstream languages just can't compete with Lisp. And it's not just a Lisp thing. Listen to Python or Ruby folks talk about how much more productive they are in those languages versus Java or C++. There is a reason for that. It's because those languages are more like Lisp.

Re:The problem with patterns

[be-fan]

Undoubtedly. Design patterns are helpful in any code, they're just easier to use when the language is properly set up to handle it. Now, it's true that a lot of people can't afford to "non standard" tools. The potential for being blamed if something goes wrong is quite high indeed. However, my point was merely that mainstream languages are not ideally geared towards working with patterns. That does not mean that they'll always be that way, however. Mainstream languages are increasingly ripping entire pages out of the books of dynamic languages (eg: Java 1.5, C# 2.0). Over time, the tools will get better, and looking at what existing dynamic languages do know could give you an edge when the mainstream languages incorporate their features.

Re:worth it for one reason

[Anonymous Coward]

Unless of course, cElement is a cParent. In that case inheritance makes sense.

A circle "is a" elipse. Should a circle class extend an elipse class, even though a circle doesn't behave as an elipse (e.g., one cannot independently alter both axis and still have a circle). Nope. "is a" is not what matters. "behaves as a" is what matters.

Re:The problem with patterns

[IvyMike]

If you program in C++, you should take a look at "Modern C++ Design" by Andrei Alexandrescu. To quote Herb Sutter's blurb off the back cover, "Fundamentally, it demonstrates 'generic patterns' or 'pattern templates' as a powerful new way of creating extensible designs in C++ -- a new way to combine templates and patterns that you may never have dreamt was possible, but is." Ultimately, he gives the reader pre-packaged generic implementations of several of the more common design patterns.

Alexandrescu's pretty far out there on the bleeding of template usage, and many of the tricks he pulls are more complex than I'm willing to embrace, but it's a fascinating book nonetheless.

Re:worth it for one reason

[AveryT]

"Prefer composition to inheritance."

More to the point, don't use inheritance when you mean composition. Inheritance models the relationship "IS A". Period.

If the sentence "A Foo is a Bar" doesn't make sense or isn't true, you should never write the code:

class Foo : Bar { ... }

But this has nothing to do with Design Patterns; this is just OOP 101. Any C++/Java/C# developer who doesn't understand and practise this has fundamentally misunderstood the OO paradigm. Reading a book about GoF patterns at this point is probably just going to make matters worse.