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

Well deserved

[Sv-Manowar]

Its good to see these people being recognized for contributing such a useful concept to object oriented programmers, and its wholly appropriate they should recieve such an award from a group focused on exploring "implementation and efficient use" of programming languages. Although they have their critics, Design patterns have surely helped many programmers greatly in this manner, especially in languages such as java.

Re:terminology, methods, what?

[smittyoneeach]

It serves as a common language for designers to talk about what they're doing.
It gives standard terminology for talking about, among other things, how you'd implement an undo function in an application.
However, such standardization flies in the face of the need to re-invent the wheel and sell it as a shiny new technology.

Re:terminology, methods, what?

[IntergalacticWalrus]

It's all about "design patterns", ie. the sorting and naming of common design problems a programmer has to face in object-oriented programming, and how to solve them right, so the code remains as maintainable and cohesive as possible.

For anyone doing object-oriented programming, this should be required reading IMHO. It gives you a solid base on how to solve most moderately complex problems.

For OO fans...

[William Robinson]

This site [ootips] is one of the best.

An Excellent Book

[under_score]

It surely deserves this award. However, after 15 years doing software development, I now consider two other books even more important even thought they are not quite as information-full as the design patterns book. They are: "Agile Software Development" by Alistair Cockburn and "Software Craftsmanship" by Pete McBreen. I have a full list of books, web sites and tools that I recommend at my Software Resources [berteig.org] page.

worth it for one reason

[bmac]

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

Easily mastering design patterns

[De Lemming]

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 [amazon.co.uk], 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.

Re:As mentioned by Paul Graham

[be-fan]

The loop macro itself is an acquired taste, but Lisp doesn't have any particular problem with it. C++ programmers try to find a "for loop" in Lisp, but there isn't really an equivalent. There is a 'for' macro of course, but it's not like in C++ where its used for all iteration, even when it doesn't really make sense. Instead, Lisp programmers use a range of iteration techniques that fit the bill. They use map, mapcar, for, dolist, etc, whichever makes sense in the given spot. In Lisp, there is almost always an iteration construct that expresses exactly the iteration you want to do, without you having to try and figure out how to express your iteration in terms of 'for'. Of course, if there isn't, you can always use loop, or write a macro to roll your own.

An Excellent Book-Plus one

[Anonymous Coward]

The laws of software process: a new model for the production and managment of software by Phillip G. Armour

The Art of Interactive Design by Chris Crawford.

Designing and writing Online Documentation by William Horton.

Technical Editors Handbook by George Freeman and Deborah A Freedman.

Bugs in writing: A guide to debugging your prose by Lyn Dupre.

Re:Head First Design Patterns

[Anonymous Coward]

Thanks De Lemming, we appreciate it. We stood on the shoulders of gaints to write Head First Design Patterns. You're totally, right, our books are for learning, grab GoF for ref. ;)

Eric Freeman

Christopher Alexander: The true originator?

[0x1234]

When I was in college, an architecture student friend of mine suggested that I read two books by a guy named Christopher Alexander: A Pattern Language (1977) and Timeless Way of Building (1979).

I'm fairly confident the concept of design patterns truly originated with these two books. The concept from architecture was then applied to software.

The fundamental idea being that there are certain components of architecture that "just work" and "feel right". They may solve very complex problems in elegant and subtle ways. They are not usually designed, but instead are discovered.

Interestly enough, I believe that Alexander himself wasn't an architect, but a physicist with an interest in architecture.

I hope that Alexander was mentioned ;)

Re:As mentioned by Paul Graham

[be-fan]

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.

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

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.

Re:As mentioned by Paul Graham

[be-fan]

Your point is well taken, but note that your problem is basically a combination of lacking documentation and you still learning the language. The first is the fault of the language (well, the implementation, but still), while the latter is nobody's fault, because it's an inevitable situation. I would assume that if you were on the clock, you would already know the language you were working in. Ie. if the project were in C++, you'd already know C++, or else you wouldn't have gotten hired to work on it.

What implementation are you on, anyway? Depending on what kind of networking you need, the trivial-sockets [cliki.net] library could be up your ally. Very simple way to connect Lisp to a network. If you're on SBCL, there is SB-BSD-SOCKETS [sbcl.org], which exports an API pretty similar to standard UNIX sockets. Of course, for the best in documentation quality, springing for a copy of Allegro CL will get you the ACL socket API [franz.com]. Since you're a student, you can get a copy for a mere $99, or about what you'd pay for an academic version of any other commercial software.

Re:worth it for one reason

[plover]

Even your example has a counter example.

I just saw a presentation where the guy gave an example of a CSquare inheriting from a CRectangle. He said look at the differences: if your CRectangle has a SetSize(int height, int width) method, what do you do if the width isn't the same as the height? Perhaps you should have a SetSize(int side) method instead. But then it's still different enough that the two really aren't as related as they seem, even though a square is most certainly a rectangle.

I agree that inheritance is overused. Yes, it has its place, but I think that place is in defining an interface rather than in trying to reuse functionality.