'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

As mentioned by Paul Graham

[putko]

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.

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.

Re:As mentioned by Paul Graham

[EvanED]

I must admit that I have never programmed in Lisp (my functional languages experience is limited to ML), but I would bet a substantial sum that there are at least a few idioms in Lisp that could be considered analogous to the OO design patterns that an OO language makes invisible.

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:As mentioned by Paul Graham

[whatthef*ck]

So, rather than bemoan the fact that there aren't as many Lisp jobs as C#/.NET jobs, why not try to integrate Lisp into your current job whenever possible?

What for? What would Lisp give me that I can't get from Java, Perl, C, C++ or bash, that would be worth the effort it would take to learn a language there's virtually no market for?

Assuming of course you're actually interested in expanding your skills.

Only to the extent that there's some practical use for the skills I'd be acquiring. And I don't count among practical uses the ability to pretentiously extol the virtues of near-dead niche languages, the way tools like Paul Graham do.

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.

Re:As mentioned by Paul Graham

[be-fan]

Not really. I haven't encountered a feature of Java or C++ that is not directly expressible in CLOS. This includes fancy new Java 1.5 and C# 2.0 stuff like properties, etc. Now, once you get out into real OO languages, like Smalltalk, you might find something, but its doubtful.

Beyond that, as Graham points out, there are few patterns in well-written Lisp code. If a Lisp programmer finds himself repeating the same pattern of code over and over, he'll just write a macro to codify the pattern. It should be noted that CLOS itself is mostly just a big macro package. Now, compilers generally have some knowledge of CLOS these days, for optimization purposes, but they don't really need to.

Re:As mentioned by Paul Graham

[shmlco]

I just can't help myself given that sentence. To quote, "Language bigots always think they're language is perfect."

Yes, language bigots always think THEY ARE language is perfect.

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:As mentioned by Paul Graham

[EvanED]

Beyond that, as Graham points out, there are few patterns in well-written Lisp code. If a Lisp programmer finds himself repeating the same pattern of code over and over, he'll just write a macro to codify the pattern.

First, duplicated code != a design pattern.

Second, what can a Lisp macro do that, say, a C macro or a function can't? (I ask merely for information, I'm not challenging you.)

Re:As mentioned by Paul Graham

[swimmar132]

A Lisp macro is absolutely nothing like a C macro. They do completely different things, so you can't compare them.

Re:As mentioned by Paul Graham

[jjhlk]

I think Lisp macros can do things with the AST, wheras C macros manipulate text. That is, one is about as powerful as a compiler, and the other is about as powerful as a preprocessor.

But, I'm a programming amateur and use neither C nor Lisp.

Re:As mentioned by Paul Graham

[sv0f]

A Lisp macro is a function that is applied at compile time, not run time, so in this sense it is not like a C function.

A Lisp macro performs an arbitrary rewrite of a Lisp expression into another Lisp expression. Because Lisp programs are expressed as Lisp data (i.e., lists), and because the full power of Lisp is available to implement this transformation, it is much more powerful than a C macro.

The upshot of this is that macros can be used to extend the control structure of Lisp itself. (Think templates on steroids, perhaps.) This allows you to (more) neatly encapsulate what would be a complex idiom or design pattern in languages that lack similarly powerful macro facilities.

(Scheme, the bastard offspring of Lisp and Algol, has a "hygenic" macro facility that has a number of interesting properties. Dylan, a Lisp with more conventional syntax, also has an interesting macro system. I am unaware of any other comparable languages in this regard.)

I hope this helps.

Re:As mentioned by Paul Graham

[teknomage1]

I'm bsting my ass to learn lisp based it's ability to map to my problem domain, but it's damn hard to fnd documentation on how to interface with the rest of my system facilities for the free lisps. That's a barrier to entry at least that may be impractical for many. Also all this research (on socket programming in this case) Is really killing the productivity gains the rest of the language provides. As a college student this isn't a deal sealer for me, but if I were on the clock...

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 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, 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. 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:As mentioned by Paul Graham

[rsheridan6]

There is no "for" macro in Lisp, though there is a "for" keyword in the loop macro. There's nothing stopping you from defining one yourself, of course.

Re:As mentioned by Paul Graham

[Brandybuck]

The best evidence is the dearth of mainstream applications written in lisp. By "mainstream" I don't mean commercial, I mean some application or utility a non-programmer would use.

For a language that's as old and as evangelized and as well liked as lisp, this is very strange.

Re:As mentioned by Paul Graham

[lordDogma]

Doesn't matter. Lisp sux. No one uses it except for people who can't let go of the past.

Re:As mentioned by Paul Graham

[some guy I know]

I haven't encountered a feature of Java or C++ that is not directly expressible in CLOS.

My guess is that you meant "a feature of the Java and C++ class systems".
I can, off the top of my head, think of three things that you can do with C++ that you can't do with CLOS, or even CL (except through external libraries):

• Point to and dereference absolute memory locations (needed for device drivers, etc.), or use pointers in general.
  (Yes, the cdr of a cons is (usually) a kind of pointer, but it can't point to an arbitrary memory location (such as into the middle of a string).)
• Allocate and free memory, especially "force" free memory (delete an object) to trigger an object's destructor.
  (Yes, you may be able to force GC (I think, although I can't find a function in CLtL to do this), but not (AFAIK) for a single object (and, even then, I don't know whether the CL spec guarantees that all unreffed objects will actually be collected during forced GC (if there is such a thing as forced GC, about which, as I mentioned earlier in this (relatively) very long, and overly punctuated (and overly parenthesized), sentence, I am not sure)).
  And, yes, I know that it's generally bad practice to delete an object that may have pointers pointing to it, but this is an example of what you can do in C++ that you can't do in LISP, not what you should do.)
• Force cast an object of one type to another incompatible type while leaving its bit pattern intact (e.g., float to long and back, to examine and modify the float's internal structure using C++'s bit-twiddling operators).
  If you want to do this in most versions of CL, you have to write the float to a binary string-stream using a binary file function in the "EXT" (external) package (which is not part of "standard" CL (although it's usually the same extension in many CL implementations)), read it back in as an integer, do the examination/operation, write it back out to the binary string-stream, then read it back in as a float.

Granted, most of the time you don't want to do these things, and LISP (and, to some extent, Java) prevents you from doing these things accidentally, but if you want to do these things on purpose, you can't in (most dialects of) LISP (without relying on external libraries).

Re:As mentioned by Paul Graham

[Brandybuck]

Thank goodness I'm not a language bigot then :-)

Re:As mentioned by Paul Graham

[theonetruekeebler]

And I don't count among practical uses the ability to pretentiously extol the virtues of near-dead niche languages, the way tools like Paul Graham do.

Valuing aesthetics over the mindless grinding out of product does not make one a tool. To Graham, programming is an art. If you think it has no worth beyond the paycheck it can generate, that's your right. To others, it has value beyond what it can be sold for, as any work of art has value beyond what it can fetch on eBay.

Re:As mentioned by Paul Graham

[mysticgoat]

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.

Well, yes, that's sort of true in a roundabout way. Since Perl borrowed a number of things from Lisp. And junior programmers are more productive in Python and Ruby (than Java or C++) because those languages are like Perl with training wheels.

<rd&g>

Re:As mentioned by Paul Graham

[Taladar]

If you think popularity is a good measurement for quality (programming languages or elsewhere) you really need help.

Re:As mentioned by Paul Graham

[stesch]

I would make a guess that this doesn't just hold for Lisp but any decent dynamically typed programming language.

Yes. Norvig mentions Dylan, too.

Re:As mentioned by Paul Graham

[stesch]

Language bigots always think they're language is perfect.

But it's a good idea to try to reach a certain level of perfection. If languages are so bad you need design patterns, why not listen to the users of languages without that flaw?

Re:As mentioned by Paul Graham

[unborn]

Yes, the cdr of a cons is (usually) a kind of pointer, but it can't point to an arbitrary memory location (such as into the middle of a string)

Yes it can, since strings in lisp are sequences, and you can easily point to their cdr which might be in the middle of the string.

Re:As mentioned by Paul Graham

[stesch]

In fairness, Lisp has some difficulty with more complex patterns, such as Loop.

And what difficulty do you mean? Too much choice?

Re:As mentioned by Paul Graham

[be-fan]

Good point. It must be the keyword in loop that I'm remembering. If it isn't obvious, I'm one of those people who stays a good distance away from loop...

Re:As mentioned by Paul Graham

[be-fan]

My guess is that you meant "a feature of the Java and C++ class systems".

That's true. Sorry for not being clearer. Although, I should point out that defining a library to do these things is trivial, since every Lisp with a C-FFI already has the functionality under the hood.

Granted, most of the time you don't want to do these things, and LISP (and, to some extent, Java) prevents you from doing these things accidentally, but if you want to do these things on purpose, you can't in (most dialects of) LISP (without relying on external libraries).

One thing that I've learned about Lisp is that the distinction between "library" and "language" is pretty meaningless. I mean, most of the stuff in the Common Lisp standard is library stuff. Even basic functionality is implemented as macros on top of the language. So if you have to load an implementation-specific machine-words module to do something, it's not that big of a deal.

I'd also point out that those features you pointed out have very large down-sides. They make the language much more difficult to optimize, because the compiler has to account for pointers being able to overwrite pretty much any data. Also, they require very expensive machinery within the OS and hardware (a VMM, an MMU, etc). Look at the size of the TLBs on an Athlon64 sometime. The L1 data TLB takes up as much space as all three integer ALUs put together! If you add up the space taken up by the L1 and L2 data and instruction TLBs, plus the CAM flush filter, you have enough die space to add an entire fourth integer channel, with an AGU, ALU, scheduler, and reorder buffer! Not only that, but the TLB lookup adds a full clock-cycle to the 3-clock L1 cache latency. That's a 50% performance penalty! All of this stuff would be completely unnecessary if C code couldn't overwrite random memory locations.

Re:As mentioned by Paul Graham

[Brandybuck]

Do you even know what a pattern is?

Re:As mentioned by Paul Graham

[be-fan]

Is it really surprising? Most programs are written in C, C++ or Java. By your logic, these are the only languages suitable for writing mainstream applications. That's a silly thing to say. I refuse to believe that ML, Smalltalk, Lisp, Scheme, etc, can all be well-liked by their users, but somehow "unsuitable for mainstream programming".

In reality, the problem is systematic. The commercial industry is too risk-averse to take a chance on Lisp (or any non-hyped language, for that matter), so basically you're talking about open-source code. At that point, three factors come into play. First, Lisp programmers are generally an older set. The average OSS programmer is 27, according to certain studies. So you've got a democraphic problem there. This is not to mention the biggest demographic problem of all: there just aren't that many Lisp programmers, and an even smaller number with the free time to work on an Open Source project! Second, existing systems are massively hostile to Lisp-like languages. They have VMs that don't mesh well with garbage collection. They have memory protection mechanisms that impose a "10% OS tax" on everything, but do nothing for Lisp programs which are safe without such mechanisms! They have APIs that are exposed only in C (or worse, C++!), and are usually built without any consideration to ease of binding. Last of all, you have inertia. It's easy to do things the same way as you always have. Better ways of doing things usually give way to "standard" ways of doing things.

Re:As mentioned by Paul Graham

[rsheridan6]

>I'm one of those people who stays a good distance away from loop... Good thinking.

Re:As mentioned by Paul Graham

[Brandybuck]

Your arguments may make sense why C, C++ and Java are more popular than Lisp, but it doesn't explain why Python and Ruby are as well.

Your demographics argument is species. Old Lisp programmers where young once. So where are all their mainstream applications they wrote in their youth? You can't blame bitrot, because my current FreeBSD system has dozens of utilities that are directly descended from twenty year old code. Hell, the Free Software movement itself was started by a Lisp programmer! Other than parts of emacs, where are his Lisp programs?

Re:As mentioned by Paul Graham

[be-fan]

Your arguments may make sense why C, C++ and Java are more popular than Lisp, but it doesn't explain why Python and Ruby are as well.

Consider the niches that Python and Ruby target: web programming and systems glue. There is a large body of existing code in these languages for doing those tasks. Meanwhile, consider the niche that Lisp originally occupied: AI and compiler theory. Guess which niche has more programmers?

Your demographics argument is species. Old Lisp programmers where young once.

Yes, but when they were young (or equivalently, when Lisp was much more popular than it is now), the internet either didn't exist, or was very limited in scope. Without the internet, you can only have basically one kind of open source: academic. Academic open source tends to produce a very specific type of software, a kind that is usually not very interesting to your average user. By the time the modern open source movement came around, with people working on "mainstream software" for "regular users" across the internet, the popularity of Lisp had already passed.

So where are all their mainstream applications they wrote in their youth?

They wrote lots of applications, just probably not ones you'd be interested in. If you're an engineer, you'll still run into the occasional Lisp program, and if you're into compilers or computational theory, some of the best tools are still in Lisp. Of the dozen or so programs I use regularly on my desktop (Evince, Firefox, etc), two are Lisp programs (Maxima, a mathematics package, and Emacs). Given that Lisp programmer community was never even 10% as large as the C programming community, 2 programs out of 12 doesn't seem so bad.

You can't blame bitrot, because my current FreeBSD system has dozens of utilities that are directly descended from twenty year old code.

FreeBSD is an OS. C's original niche was programming operating systems. It is no surprise that in the realm of operating systems, there is a lot of old C code. Lisp's original niche was compilers and AI. There is still a lot of old Lisp code in these realms.

Hell, the Free Software movement itself was started by a Lisp programmer! Other than parts of emacs, where are his Lisp programs?

The FSF's explicit goal was to create a replacement for UNIX. Is it really any surprise that most of the code ended up being written in C?

Today's world is UNIX-centric. The API for Windows might be different, but all the concepts (from files to memory mapping) are basically the same. As a result of being UNIX-centric, they are C centric. Ever wonder why files in every mainstream OS are untyped bytestreams? Because those are the easiest thing to deal with in C!

Lisp, Smalltalk, etc, were not just languages that ran on UNIX. During their heyday, they were alternative systems in their own right. When UNIX took over the world, these alternative systems died, and a lot of old Lisp code died with them. Python, Ruby, etc, are all much more recent. They arose in a time when the UNIX machine model had already won-out. They grew up integrated with how UNIX did things. Thus, when new programmers look at a language, they flock to the languages that integrate well with their existing OS.

Now, this does bring up a good point. The world today is very different from the 1970's and 1980's. In a very real sense, Lisp is living in the past. Lisp dates from a time when people still expected to pay for compilers. Thus, the best Lisp implementations are still proprietory. So effort has to be put in to improving the existing free implementations. Lisp dates from a time when a programming language was just a spec and maybe a reference compiler. Now, it's got to have a good, free development environment and a large stack of pre-built libraries. It would not be a strech to say that if C and C++ didn't have the kind of inertia they did, Java, Python, etc, would blow them off the map.

Re:As mentioned by Paul Graham

[master_p]

Compile time-metaprogramming is the last frontier for mainstream programming languages (*cough* LISP is not a mainstream PL *cough*).

Re:As mentioned by Paul Graham

[Brandybuck]

You're basically validating my original thesis: that Lisp is unsuitable for mainstream programming. MAYBE if Lisp machines and architectures had taken off, MAYBE if Unix and Windows didn't hijack and corrupt the minds of our youth, MAYBE if Lisp had been taught to every CS freshman for the last two decades, MAYBE just MAYBE things would be different. But in the reality of this world, Lisp is unsuitable for mainstream programming.

Re:As mentioned by Paul Graham

[whatthef*ck]

Hey, my first Freak! Thanks Carleton!

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?

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

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:terminology, methods, what?

[DrEasy]

It simply opened my eyes about what true OO was about. I thought I was already fairly proficient in Smalltalk, but it's after learning a few of the patterns in the book that I truly understood the need for abstract classes and methods, the proper use of inheritance (vs composition), and the constant fight against code duplication.

Re:terminology, methods, what?

[Profane MuthaFucka]

It's a cookbook!

(now watch someone who hasn't read the damn thing mod me down. Then, watch everyone laugh at that someone.)

Re:terminology, methods, what?

[plover]

The answer to all of your questions is "yes". It's about algorithms that solve common problems or address common issues. It's also about a common set of names, so that designers are less ambiguous when they talk to each other.

Also important is that it lets you know of the "consequences" of using a given pattern, both good and bad. If you employ the composite pattern, for example, you treat a group of objects the same as a single object, and the container will recurse through the children.

The other thing about patterns is: they're not new. People have been doing these things long before they were named. Patterns are simply a way to share that expertise. The Gang of Four recognized this, claiming not that they invented these patterns, but rather discovered them.

I'd say almost any programmer who's serious about their craft can benefit from the book, but it will help you to have a working understand of basic object oriented concepts and terms before reading it.

A beginner might also benefit from a companion introductory book, too, such as Design Pattern Hatching. It goes through a fairly simplistic set of example problems facing a developer, and how matching patterns up with the problems can lead to a better, more maintainable and more flexible design. Plus, the coding is easier when you have a solid example to follow.

Re:terminology, methods, what?

[Linus Torvaalds]

It's easy to talk about control structures like for loops, functions, etc because they have names. It's easy to say things like "it's insane to have all that code in one function".

Software architecture, which is a level more abstract than syntax and control structures, lacked such names for some time. Instead of names, you'd describe a solution or something.

If you haven't named something, you can't talk about it effectively. You can't discuss its pros and cons with people easily. And so on.

"Design patterns" is basically identifying and naming common approaches to solving problems that crop up again and again when contructing software. Once they are identified and named, you can read or write about the tradeoffs such a pattern has, the advantages of one pattern over another, and so on.

They can be solutions to small problems or large problems. Beginning programmers can apply patterns to their smal problems, and as they grow in ability, learn the larger patterns as they need to. It's valuable in this respect, because you will be inheriting the experience of other programmers as you learn these patterns.

Re:terminology, methods, what?

[uncqual]

The patterns are also nice because if everyone on a project uses them as applicable (rather than inventing their own solution), it makes it substantially easier to follow each other's code. In part because the comments can often reference the pattern used (if this is even needed) and perhaps any oddities about how it is used rather than reexplaining the wheel each time; in part because code just looks familiar when the standard patterns are utilized (of course, minor errors may be less visible because it's easier to not actually read the code if you think you know what it does!).

Re:terminology, methods, what?

[syousef]

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)?

Design patterns are recurring algorithms in software design. Take the "Singleton" pattern, which is usually regarded as the simplest. You use a private class variable, and a public getter (and either a setter or lazy initialize on the first get). What you're trying to do is make sure there's one and only one instance of a variable on the whole system.

The other classic pattern is the MVC (Model-View-Controller) pattern. Separate classes for the model, the view and a controller to perform the logic. Model and View can then change independantly with the Controller tying the two together.

Note that the following is not a popular view. Design patterns are all the rage at the moment, so much so that you're less employable if you've had no exposure to them. But in all honesty I couldn't care less about fashion in the computer industry. Fashion is for sheep. Can't care less if it's mistaken for flamebait either because it's not.

Well I've had a good look at patterns and I tend to swear at them. The idea isn't bad in itself but the approach is. I'd definitely recommend you learn about them so you can talk the talk but here's my problem with them.

Patterns try to take a cookie cutter approach to a problem. They encourage bad analysis. They encourage the "oh I've seen this before" mentality, when in fact the problem may be different to what you expect if you're trying to force it into one of the patterns you know.

In other words patterns encourage you to jump to conclusions about what is going to be the best solution without necessarily fully analysing the problem. Now if the problem is exactly what the pattern is designed to tackle, there probably isn't a better solution. But if it only looks like it's the same problem, you end up solving the wrong problem.

Unfortunately unlike a standard cookie cutter people will over-engineer and layer 100 patterns into a problem. They throw the KISS (keep it simple stupid) principle out the window and try to see how flexibly they can design a system by putting in as many patterns as possible.

What you end up with is something 100 times more complex than it should be, that's hard to maintain and has no advantage over a simpler system because application code is rarely extended in a foreseeable way. Coping with 100 different possible extensions makes the code ugly and cumbersome. (For starters you better hope everyone on the project understands patterns). You're better off putting in the complexity when it's requested.

In my opinion Design Patterns have a place when used in moderation and sensibly. That place is in frameworks. When you're building something that needs to be reused in many places, this is when you want all those patterns put to good use.

Another problem is that they're not the most intuitive idea, and you WILL work with other developers that don't understand them. If you can't downshift and stop talking patterns you'll have trouble communicating. (Some of these patterns do very obvious things that you probably already know but don't know the name of the pattern for - singleton for example)

Is it good reading for an amatuer programmer, or more as an advanced topic?

It's advanced but if you're interested in being a good software professional it's pretty much required reading these days.

So here's what I think you should do. Buy, borrow or steal the design patterns book. Go through the examples of each pattern. Understand what it's trying to do. Have it there in the background. If you genuinely have a problem that falls into the category or if you're working on a framework ask yourself where the patterns should be used. Use them sparingly. Knowing this stuff is good. Using it everywhere is as silly as using any other tool everywhere.

When you're reading, always focus on the "Intent" of the pattern.

Remember there are no silver bullets! Don't start using them everywhere.

Re:terminology, methods, what?

[heinousjay]

You've looked at the idea of design patterns and tried to fit them to a problem that you were attempting to solve without analysing that problem, right here in your post. It's sort of poetic that you complain about design patterns being misused this way.

The most important thing the concept give us as software professionals is a common vocabulary for things we were all already doing over and over. It's not that the intent was to use these patterns to solve every problem, and it says right in the book that it's not complete. It just formalizes the notion of the solutions that were being widely used so that people could start concentrating on different abstractions.

What encourages bad analysis is the shortcut mentality, which is present regardless of the information available beforehand.

Re:terminology, methods, what?

[Pseudonym]

Exactly. I'm glad someone said this first.

The whole idea behind design patterns is that if something keeps turning up in your software designs, you should give it a name and try to pin it down semi-formally so you can talk about that thing independently of any specific application.

This sort of thing happens in mathematics, too. Abstract algebra, for example, is built on the idea of abstracting away the differences between, say, different "rings", so that you can talk (and prove properties of) all of them without referring to any specific ring. (Category theory is even moreso, but a discussion of this is beyond the scope of this message.)

Re:terminology, methods, what?

[syousef]

You've looked at the idea of design patterns and tried to fit them to a problem that you were attempting to solve without analysing that problem, right here in your post.

Why is it that extreme fans of concepts and paradigms tend to attack those who point out the flaws in those approaches, instead of counter-arguing the legitimate points raised? I think my analysis was both through and accurate and I challenge you to shoot down the argument instead of brushing me off as not having thought things through.

Someone asked whether design patterns are worthwhile and why people would "swear by them". What I've given, based on my own experience, is a summary of how design patterns are used and abused. I believe I have a good grasp of how to use them and what they're good for. I also see how they're actually used. Given the abuse the concept gets they can be harmful.

The most important thing the concept give us as software professionals is a common vocabulary

If that's so it's a confused vocabulary. For a start it's not descriptive of the abstract structures developers code, but is tied to the intent of the solution (sometimes to the point that a single solution could ambiguously be described as two or three of the classic patterns). What's more, as you say it's not complete. You cannot assume that anything beyond the patterns listed in the classic GoF book are well known. It's like having a dictionary with a set of about 20 words, two of which are "dog" and "canine".

What encourages bad analysis is the shortcut mentality, which is present regardless of the information available beforehand.

There's a fine line between a paradigm and a specific "shortcut mentality".

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.

Short reply

[rbarreira]

Why are you giving the credit to Paul Graham?

He isn't.

For OO fans...

[William Robinson]

This site is one of the best.

Re:For OO fans...

[Ravatar]

Thanks for the link, didn't have this one bookmarked.

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

[putko]

That happened at UCB? That's terrible news. It wasn't always so, of course.

Check out that first comment: 16 of the 23 patterns are so simple as to be invisible when you use the right tools.

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

[fishbowl]

You actually know someone with a CS degree from Berkeley who can't keep up with you on any of those topics? Or are you just guessing?

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

[be-fan]

LOL. I find it depressing that I know most of what those words mean, but I'm an aerospace major. I learned most of them in my EE courses and from hanging out on comp.lang.lisp...

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

[justine_avalanche]

Don't be so quick opposing the computer science theory and software engineering techniques (why would they be mutually exclusive anyway?).
You would be surprised how much knowledge of "turing machines" (finite state machines are used in many algorithms), "functional languages" (what's wrong with them?) or "planar graph" (graph and other data structures knowledge might be the difference between a problem solved elegantly and the same problem solved with a clumsy solution) can actually help in the construction of software.

I'm not sure how Goedel fits in there though ;)

Re:Oh dear...

[Kupek]

Programming paradigm. It's the most appropriate word to describe the different families of programming styles/languages: procedural, functional, object-oriented, imperative, logic and such. It's commonly accepted; I've seen it in places ranging from textbooks to CS papers to Stroustrup's C++ book.

Re:Oh dear...

[pilkul]

You would be surprised how much knowledge of "turing machines" (finite state machines are used in many algorithms), "functional languages" (what's wrong with them?) or "planar graph" (graph and other data structures knowledge might be the difference between a problem solved elegantly and the same problem solved with a clumsy solution) can actually help in the construction of software.

Yep. By a remarkable coincidence, I actually happen to have a summer job working at (guess what!) a trucking company struggling with logistics. I'm using the Filemaker database software --- a pragmatic, business-oriented RAD system if there ever was one. And it so happens that Filemaker's automatic field calculations are written in a functional language, and that Filemaker internally uses graph-theoretic algorithms to trace the dependencies between these calculations.

It should be an obvious point really, but both CS-ish knowledge and SoftEng-ish knowledge is important to be a skilled programmer. (Though I will admit that given a choice between only one or the other type of knowledge, I would choose the SoftEng guy to build my business system...)

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.

Re:Oh dear...

[TemporalBeing]

I can't quite tell if you got his point or not...but I think at least most of the others that responded to him did not.

The problem with CS programs is that they are becoming too theoretical and not practical enough. And I certainly agree with him that CS should not be so theoretical, but be part of an actual Engineering discpline; so get the CS programs out of the math departments and put them under the Engineering departments as a Software Engineering degree. The students will be 10 times what they are today, and may once again reach the quality of CS people we had 20 years ago.

Re:Oh dear...

[au miau]

"most useless book" is a great definition of all that (unfortunately it is not just a book)
  I think that the right words for Design Patterns ...as for Object Oriented Programming itself are "brainwashing" , next after Fortran, AI , structured programming ...(IT is fruitful place for politics if not for science)
  Smalltalk was a great language but everything was poisoned by "object oriented" mammal and vehicle subclass hierarchies in so many books and lessons A funny remark here is that french philosopher and sociologist Jean Baudrillard wrote a book entitled "Le Systeme des objets" in 1968 and he didn't find them so exciting ...and was it worthy to re-invent Object Systems in programming few years later ?And Design Patterns are just the second iteration of all that a - kind of "relative object orientation"
  When in 1960 Richard Karp discovered *smalltalk 60* he understood the consequences of his discovery and spent years in complexity theory (- he got the Turing too ,so maybe not only bad taste is awarded)
  Just imagine an IT world in which OOP and Design Patterns are invented in 1960 :-) ... sounds terible but I'm afraid there are people who always tryed to do that

Re:Oh dear...

[cratermoon]

Goedel fits in there because the incompleteness theory is not unlike Turing's incomputability problem.

Re:Oh dear...

[EastCoastSurfer]

It's no accident that non object oriented langauges like Lisp and ML don't have quite so many design patterns.

OO langues provide some facilities that make implementation easier, but every language can have design patterns. All a design pattern is, is a solution to a common design problem. The only way a language would not have any design patterns is if it allowed you completely skip the design phase.

Re:Oh dear...

[Peter La Casse]

It's true that CS undergrads do need exposure to SE basics, but moving the CS program into the engineering school is overkill, because there is a need for theory-heavy CS programs.

Creating a Software Engineering program in the engineering school is a better idea; it and a CS program could complement each other nicely. SE undergrads need some basic amount of theory, which they could get from the CS program, and CS undergrads need some basic amount of SE knowledge, which the SE program could provide. The other engineering programs could provide the SE program the kind of procedural rigor that real engineers take for granted and that SE desperately needs.

Exceptional students (whether they intend to become computer scientists or software engineers) could double major in both CS and SE, just as today, exceptional students sometimes double major in CS and Computer Engineering or Electrical Engineering.

An alternative would be to alter undergrad degree requirements so that a bigger part of a student's course load is in their department. At my alma mater, of the 120 credits required for graduation, 40 were breadth requirements, 40 were general electives and no more than 40 were allowed to come from a single department. Changing that last limit to 60 would let you add a complete undergrad SE curriculum to an existing CS curriculum.

Re:Oh dear...

[justine_avalanche]

> Face it; software is now a commodity business

I think this is the worse misconception around. When you think that more than 50% of all projects do not see the light of the day, and for those who get completed, only a fraction are considered a success ; how can one just say 'oh it's a commodity'.

The pc hardware is for sure, but I really don't think the software's there at all. I don't understand why people keep repeating this when it's obviously wrong.

Re:Oh dear...

[joss]

> software is now a commodity business

A commodity business is one where almost the exact same product can be purchased from multiple vendors. This is true for a few established software products like RDBMS or spreadsheets, but new software development is not a commodity at all. You might as well claim that writing novels is a commodity business.

Re:Oh dear...

[reflective recursion]

With higher level languages, design patterns disappear.

For example, in Lisp and Scheme we have the MAP function. In other languages, MAP would be a design pattern. This is why design patterns are bunk. If you discover such a pattern in Scheme (et al.) you simply bottle it up for the next time you need it. You don't need to run and search through a book to find the pattern which fits the problem you're trying to solve because you have one tool and that tool works damn well.  The "closure" concept, first-class functions, and macros make design patterns obsolete. The thing with Scheme, etc. is that you never encounter the same problem twice. If you do, you're definately running into something that should be placed in a library. If you think Scheme/Lisp is incapable of packaging all design patterns, then you probably haven't discovered "functors" and/or functional objects. When working in Scheme you are always working at solving the problem. You don't worry about solutions to solved problems.

Another example, the Abstract Factory pattern:

(define (make-car-factory aquire-tires
                          aquire-engine
                          aquire-chassis)
  (lambda ()
    (let ((tires (aquire-tires))
          (engine (aquire-engine))
          (chassis (aquire-chassis)))
      (list tires engine chassis))))

(define aquire-firestone-tires
  (let ((serial-number 123))
    (lambda ()
      (set! serial-number (+ serial-number 1))
      (string-append "firestone-tireset-"
             (number->string serial-number)))))

(define aquire-kent-engine
  (let ((serial-number 567))  ; a second "design pattern"
    (lambda ()
      (set! serial-number (+ serial-number 1))
      (string-append "kent-engine-"
             (number->string serial-number)))))

(define aquire-ford-chassis
  (let ((serial-number 890))
    (lambda ()
      (set! serial-number (+ serial-number 1))
      (string-append "ford-chassis-"
             (number->string serial-number)))))

(define make-ford-pinto
  (make-car-factory aquire-firestone-tires
                    aquire-kent-engine
                    aquire-ford-chassis))

(define my-car (make-ford-pinto))
(define your-car (make-ford-pinto))

my-car
;=> ("firestone-tireset-124" "kent-engine-568" "ford-chassis-891")

your-car
;=> ("firestone-tireset-125" "kent-engine-569" "ford-chassis-892")

It took me a minute to even figure out what the pattern was trying to do (I couldn't remember). Implementation took less time than making sure I was following the pattern correctly.

Re:Oh dear...

[patternjuggler]

Programming paradigm. It's the most appropriate word to describe the different families of programming styles/languages

If it always comes qualified with 'programming' at the front then it may be okay- also there's a difference between having a word written down and hearing it in speech, something about written words make them more respectable. I would avoid usage of 'paradigm shift', 'different paradigm', or 'new paradigm' at all costs.

Re:Oh dear...

[bclark]

I'm an undergrad CS major at Berkeley, so I can say that you are absolutely wrong, at least with your choice of school. The CS departments at hundreds of other universities might be churning out people with CS degrees that are really Software Engineering or Information Technology degrees, but Berkeley is not. That's why it's consistently ranked as one of the best places for CS, both at the undergraduate and graduate levels.

As far as your specific examples, I learned about all of those in my first 2 years here with the exception of "Rice's theorem", but I'm taking Theory and Algorithms next semester so I imagine I'll hear about it then. The software engineering buzzwords you used, however, I know what "reflection" is but have no idea what the other stuff is at all.

I leave it up to everyone else to judge what is more important. If you wish to do research as I do, then I think it is important to learn the first half, but if you're working as a code monkey somewhere, the second half is probably better. If you can't understand that they are two completely different things, then God help you.

Re:Oh dear...

[nate nice]

"so get the CS programs out of the math departments and put them under the Engineering departments as a Software Engineering degree"

I disagree with this somewhat. Although there are probably other ways, I think math is rather important for a couple reasons. First, it's pure problem solving. You're given problems in a domain that can be solved with the tools you're given. It reminds me of the same process I use for writing software: Analyzing a problem, determining what is needed to solve it and applying these steps in a logical and correct manner.

Two, math opens a new view of the world to people that study it and learn to appreciate it. I feel lucky to be a person in the world who was given the opportunity to learn as much about math as I did. I would feel like my education was worth less (note, not worthless) if I didn't get the math discipline I did.

In conclusion, if you just want to stamp out workers (maybe that is a prerogative?) then ditch the math and make a hybrid program that is a combination of MIS and computer science with the fun theory stripped out. This way you're teaching people how to program for about 4 years. You can count on me, and anyone else interested in CS, not signing up.

A good CS program will offer all the basics as the parent poster mentioned and make available many engineering type courses that focus on design and the "process" in general.

Re:Oh dear...

[henni16]

Actually, a "trucking company struggling with logistics" can very likely avoid some struggle if they have someone who knows about "planar graph"s/graph theory..

Re:Oh dear...

[TemporalBeing]

Doing as I am suggesting would not degrade the math discipline within CS in any manner. In fact, it might actually improve it. Engineers do a lot more math than most any CS program.

Re:Oh dear...

[TemporalBeing]

CS needs better ground-work. Any degree that is too theory oriented does the student no good. CS programs have become this way. By rooting them in an Engineering department, the practicality of the degree returns, and the usefulness of the degree and quality of the students will get better.

Additionally, rooting CS in an Engineering department does not mean that the students will lose the quality of theory either - Engineers do a lot of math and also a lot of theory. But they also realize that to use and create the theory you have to understand and be able to use the factual. CS students are getting to the point now where they do not understand the factual.

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

Experience for the unexperienced

[dubbayu_d_40]

Common sense for the rest of us. It was a good idiot filter back in the day...

Re:Experience for the unexperienced

[dubbayu_d_40]

Dream on.

Re:Experience for the unexperienced

[fingerfucker]

Go lubricate yourself.

Excellent material, often taught incorrectly

[bsandersen]

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.

Re:Excellent material, often taught incorrectly

[Brandybuck]

Instead, what I often see if people spouting pattern names like one would name-drop at a party

I'm seeing this at work, and it's driving me nuts. Our new Bible is "Architectural Design Patterns". The big push right now is to move to .NET because "it's enables Reflection."

Re:Excellent material, often taught incorrectly

[SirSlud]

Can somebody please give me a link to a rundown of how reflection improves software engineering? Is it for debugging purposes? To make it easier to write safe code for dynamic classes? I understand the concept, but I still havn't see the killer app.

Re:Excellent material, often taught incorrectly

[hritcu]

This was the case only until this book came out: Head First Design Patterns. Really an amazing book, I would recommend to anyone who is serious about learning design patterns.

Re:Excellent material, often taught incorrectly

[nebby]

You can do a lot of useful tricks with reflection when its mixed in with code generation, for what it's worth. Ie, dynamically build a custom class on the fly, compile it on the fly, and then instantiate it on the fly.

For example, the persistence framework we use actually generates proxy classes on the fly that handle transaction management, etc. Hooking into these things (and determining how to build them) requires some advanced reflective techniques.

I'll put a cheap plug here, since it's awesome: www.x-tensive.com

Another thing we use it for is to dynamically build and hook into older versions of our libraries for building SQL migration scripts. For example, our tool will revert source back to the previous revision, build the stuff, dynamically instantate the class, save the database schema required, roll it forward, build, repeat, and find the "SQL diff" of the two databases which we then tweak for migration purposes. Doing this elegantly and cleanly would not be possible without reflective techniques.

Re:Excellent material, often taught incorrectly

[Brandybuck]

Reflection is a nice pattern. But the ADP book treats it as an *architectural* pattern. As in, it defines the entire structure of your system. Consequently, the architectural team at my work is making a brand new system based on the reflection pattern.

My coworkers aren't stupid, they've just getting a lot of positive feedback from their use of buzzwords.

Re:Excellent material, often taught incorrectly

[plover]

The only place I see it being of serious value is in automated software testing. JUnit (for Java) and NUnit (for .NET) both rely on reflection to discover the unit tests in your code and execute them.

There's also a unit test framework for C++ called CppUnit, which was intended to bring the benefit of more formal unit testing to that language. However, since C++ doesn't support reflection, you end up having to employ macros to use it. It's not self-discovering.

Otherwise, I haven't noticed its absence from C++.

Re:Excellent material, often taught incorrectly

[khchung]

How true. A few years ago, I met some guy who asked me "What patterns have you used before?" and I thought "WTF?!", and after trying unsuccessfully to understand what he is asking, I answered "I use patterns as I need them." and then named a few I can recall in the moment.

Only later, after hearing more of these kind of moronic questions did I realize that patterns have became the latest buzzword among "software architects", just like OOP had before when people asked "What objects have you used before?"

Such questions have become a bright flashing signal for me to identify "architects" who can't do their job.

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

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:worth it for one reason

[bmac]

They don't (as I remember) say to avoid
inheritance at all costs, but rather to
only use it where needed. And in my
many years of programming, polymorphism
has rarely been needed. Off the top of
my head, the only time I've needed it
was when implementing a simple window
manager where each different control
needed to implement the standard control
fcts onKey and onMouse or somesuch.

Personally, I'd say that I prefer to
use an enum for the obj's type and then
use a switch to handle the different
cases within the member functions. I
know it's considered bad-practice, but
it does keep all the code in one place.
Now, if each different type has vastly
different data associated with it, then
true polymorphism is my choice.

Due to the fact that my software projects
get larger every year, I am generally more
concerned with source code management
than cuteness of structure. It seems to
me that keeping everything within one
file and class makes it easier to create
and debug and *edit*. Whether using
ultraedit or vs.net to develop code, my
biggest complaint is how few items on my
tab strip can be seen at one time. When
dealing with the relations between many
different levels of a system, going from
file to file is essential. Of course,
what I really want is to have the file
names organized in layers so that their
source relation (as I visualize it) would
be reflected in the file selection tab.

Of course, that is what my work revolves
around. We programmers must always remember:
if we have complaints about the tools we
use, we should just write our own!

Peace & Blessings,
bmac

Re:worth it for one reason

[nkh]

Maybe what the GP meant is that there is too much inheritance without a good reason behind it. I'm reading a book on design patterns right now and they just give you this as a piece of advice, not an order: "don't overuse inheritance when you just need to create a structure." Inheritance is a good thing but in the end you still need members to keep the info and as you said it perfectly "everything has its balance."

Re:worth it for one reason

[sean23007]

JEdit has a plugin that list all the open tabs in a pane on the right side of the screen. Using that, you can view like 30 filenames at once, compared to only like 8. I use it for all my coding. I just wish it were a bit snappier on OS X, but it flies on Linux.

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:worth it for one reason

[strider44]

Exactly. I'm actually programming a small GUI class at the moment for a C++ OpenGL project I'm working on, and inheritance for the widgets make a lot of sense, simply because when you have the three events that I need to account for (render, mouse click and mouse move) it is extremely simple and convenient to have a base class with the three virtual functions in a linked list so the GUI class can loop through them.

Inheritance and composition are different tools, and are used for different purposes. Sure sometimes they overlap, but most of the time they achieve different things.

Re:worth it for one reason

[Brandybuck]

That's nit picking. It's anal attention to trivialities like this that leads people to completely avoid inheritance.

Re:worth it for one reason

[snorklewacker]

Personally, I'd say that I prefer to
use an enum for the obj's type and then
use a switch to handle the different
cases within the member functions.

Our browsers
handle line
breaks just
fine thank
you.

Anyway, congratulations on reinventing polymorphism. Of course by keeping all the code in one place, you no longer keep the behavior of a particular object in one place. Changed from a linked list to a hashtable? Better update 20 functions in 20 files.

I know it's considered bad-practice, but
it does keep all the code in one place.

Look into languages with generic functions like (you saw this coming) common lisp. Actually even C++ lets you write generics, though it's not quite as smart about dispatching. For a java flavor, you can try Nice.

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.

Re:worth it for one reason

[jhoger]

I agree, to an extent. But if you throw inheritance out for composition, you really need a more evolved concept of composition than is typical.

Inheritance is never necessary. But just saying "always use object composition" doesn't make sense either, in and of itself.

All objects should be considered as an assembly with a boundary, with multiple terminals to connect to other components. Each terminal can have its own interface type. Multiple interfaces nodes (connectable terminals) with different types is a much more straightforward and flexible concept than mashing all your interfaces together with multiple inheritance. It is simply unnatural to expect interfaces to mix like paint. They don't.

Why not just have a orderly constructed system of components, subcomponents, terminals and a connection broker to rig it all up? Is-a and has-a degenerate cases not worth considering. Almost all real world components of interesting complexity are a case of "this-does" where this-does breaks into naturally into multiple subfunctions (connectable terminals).

Anybody know a language that facilitates such a model (don't mention COM, please, most of that is dedicated to versioning interfaces and not really important for the main concept)? You can do this in C++ or C if you want to do all the scaffolding yourself.

-- John.

Re:worth it for one reason

[BitchKapoor]

I have a friend who's working on a language which has that model (and much much more). Reply to me if you'd like an update when he releases something.

Re:worth it for one reason

[JaredOfEuropa]

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.

No, keep reading!. The patterns are useful, and may give you insight into a better way for solving certain common problems. But far more importantly, it gives you a common language to use with fellow software engineers. I find that in the corporation I work for, more and more people are familiar with these patterns, which makes both design discussions and analysing code a lot easier. (The book is now given to students at our "OO Programming" course).

Re:worth it for one reason

[a_n_d_e_r_s]

CSquare and CRectangle should be the same type of object. There is no need to separate them into separate objects.

Re:worth it for one reason

[rookkey]

CSquare and CRectangle should be the same type of object. There is no need to separate them into separate objects.

Sure they should be separate classes. Consider:

// make a rectangle 100 units wide and 50 units high

CFourSidedPolygon rectangle(100, 50);
rectangle.setSize(200, 50); // okay, it makes sense to widen rectangles

// now make a square 50 units wide and 50 units high

CFourSidedPolygon square(50, 50); // okay
square.setSize(100, 50); // whoops, our "square" is no longer a square!

The point is that you shouldn't create classes that allow clients to violate invariants such as square.width == square.height. Either, CFourSidedPolygon shouldn't support "setSize" functionality (probably, making it a worthless class) or "squares" should be of their own class, CSquare, that contains a CFourSidedPolygon rather than inheriting from one.

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.

Re:worth it for one reason

[jhoger]

absolutely would like to hear about it ( email jhoger@pobox.com )

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

[mudbogger]

"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." Might be a little too bold of an assumption. A lot of people like myself enjoy using patterns and *gasp* do even look for ways to use them. Doesn't mean the code isn't good; I mean if there are multiple ways to write it and one is based on a standard that there is little wrong with (the particular pattern in question) and the other way is just how you intuitively think about it, the chances are the former will be more beneficial, cleaner, extensible, etc, etc, etc.

Re:An observation...

[sean23007]

I think what he was referring to was that some "pattern zealots" will go through the list of patterns and try to fit as many as possible into their program. They're operating under the same assumption that you made, that more patterns is better. However, if you are using them just to use them, you run the risk of misusing some of them. And cramming a design pattern into a place where it doesn't quite fit is what leads to bloated, bad code.

Re:An observation...

[KidSock]

Agree 100%. In fact I think OOP in general is overused. OOP is just one of many techniques that can be used in programming. I've done my share of Java and it's a great language but most of the Java code I've seen is so heavily OOP I don't think people even realize that they can occomplish the same task with a few lines of simple C-ish looking code. In the long run I think this will actually hurt Java as a language. A perfect example is log4j. That whole package is riddled with design pattern stuff where a simple PrintStream with a loglevel member would have been perfect for 9/10 apps. And yet it is considered by many people to be gleening example of Java perfection. That's what happends when you put a little marketing behind a programming language. Shrug.

Re:An observation...

[dubl-u]

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.

I mostly agree with that. I have slogged through too much code that was written for architectural coolness. Zealots for anything are, almost by definition, hopeless at anything useful. This applies to pattern zealots, object zealots, lisp zealots, and perl zealots. It even applies to computer zealots: we all know people who will spend ages creating software for a problem they could solve in 15 minutes with common household objects.

But don't throw the baby out with the bathwater. Patterns are neat, and I think anybody serious about building software should study them. They are great for a common vocabulary. And they're handy when you're struggling with a design issue: a flip through the GoF book will make you consider design approaches you might otherwise miss. Used lightly and sparingly, design patterns are very helpful.

Re:An observation...

[Bodrius]

If you're talking about relatively small programs to solve very specific problems, I'd agree with you: having to apply 5 patterns likely means you chose the wrong ones. But for a big application there are plenty of problems that may or may not benefit from different patterns.

As a Patterns zealot, a book I'd recommend to most Pattern fanatics, as well as to any Pattern skeptic, is "Refactoring to Patterns", by Joshua Kerievsky.

It's a pretty good book on moving towards and (gasp!) away from design patterns based on application requirements and their actual usefulness, and warns frequently against the common bad habits of the Design Patterns zealot (everything needs a singleton, and a visitor, and...)

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:An observation...

[Viol8]

Indeed. It seems to me we've bred a whole generation of new programmers who are great at thinking up fancy methods to use but useless at actually solving the problem at hand so what you get is bloated code that they've chucked everything in their limited repertoir in to get it working because they can't think "low level" and create a solution on their own. They have to use other peoples algorithms/methods/patterns or they're lost.

Re:An observation...

[Tim C]

Why on earth would you do that? I appreciate that you're just providing an example of how over-use of patterns can screw code up, but if someone on my team wrote code like that then they'd be rewriting it the moment I saw it.

As with all things, you can take pattern usage too far. Doing so is not unique to patterns, and as in other situations, is the mark of a bad programmer. Bad programmers are going to be bad whatever tools you give them.

Re:An observation...

[Tim C]

A perfect example is log4j. That whole package is riddled with design pattern stuff where a simple PrintStream with a loglevel member would have been perfect for 9/10 apps.

Well, that's as may be, but log4j has been my company's official logging framework for the last couple of years, and in that time all we've ever had to do with it is:

1) create a static instance of a Logger in each class that needs to log stuff
2) call the appropriate logging method to output log lines (eg logger.debug(), logger.info(), etc)

So while I'm not saying that it isn't some huge mass of over-engineered code, you most certainly don't have to *use* it in that way.

Re:An observation...

[arethuza]

Well, I'm glad to know its not just me then!

Re:An observation...

[jschrod]

This is done because some UML tools generate stub code as such. And most programmers are either to lazy to clean up the stub code, or they think `it might be needed for future enhancements' and let it in.

This is made harder that for round-trips (i.e., for reading the code back again into the UML tool) existance of the stub code is needed sometimes.

Welcome to the new world of programing by bloated diagrams.

Re:An observation...

[figa]

Patterns are an amazing tool in the hands of a bad programmer, though. Without the GOF, I don't think a bad programmer would ever think to create an AbstractFactoryBuilderAdapter that happens to be a singleton.

It used to be that a bad programmer would just write one class with one method in it. It was pretty easy to pick apart into smaller methods, then refactor into meaningful classes. With Eclipse, I can do it painlessly in a matter of minutes.

I find that poorly patterned code is a lot harder to clean up, and it's harder to tell what's going on in the first place since the classes all have the same name (*Factory, *Builder, *Adapter, *Adaptor, Abstract*) regardless of their actual function.

I don't mean to downplay "Design Patterns". It's on my desk, and I consult it whenever I get stuck on a design problem. But it's unique as a source of some of the worst programming I've ever seen. I can't think of any other CS concept that has been so thoroughly misapplied.

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, 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:Easily mastering design patterns

[hritcu]

I have been using design patterns for some years now (in fact everybody who does OOP does, whether they know it or not), but I never had the patience to read a book on the subject. They were so boring and dull, and without the proper examples, I was usually forgeting everything anyway in a couple of days, even before I was applying it into a concrete design.

Now I got admitted into a Software Engineering MSc program, starting this autumn and I really felt I had to improve my design pattern skills this summer. So I started reading this great O'Reilly book De Lemming already told you about (yes, Head First Design Patterns). It is really amazing. Although it is very long, and covers a lot of ground, I never got bored while reading it. On the contrary, I had great time, laughing very often, and implementing every pattern myself in ..... JavaScript (I don't use Java because it would be too easy, and would spoil all the fun :) ). Really an amazing book, I would recommend it to anyone who is serious about learning design patterns.

Re:Easily mastering design patterns

[LS]

This book might be good, but if so, this is a classic case of "don't judge a book by it's cover". Good grief is that cover lame!!

Re:Easily mastering design patterns

[hritcu]

I find the (girl on) cover pretty cute. What is wrong with not having a dull cover?

Re:Easily mastering design patterns

[LS]

Sorry, sometimes I forget that there are real people at the other end... :)

The problem with patterns

[be-fan]

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.

Re:The problem with patterns

[SirSlud]

I get your point, but its as unpractical as the answer, 'roll your own' to the 'are there any good X' questions programmers constantly poll the community for.

In a resource constrained sitution, sometimes you are forced to re-build the wheel. However, design patterns help people prevent having to re-invent it.

The question is; do I have to figure out *how* to build it myself, or are there recipies available out there already?

I appreciate those who work towards building smarter and better tools, but many of us simply don't have the resources and can't afford the uncertainty of re-examining the axioms of our work environment. In that scenario, its hard to argue that Design Patterns doesn't at least help people get from point A to point B without the trial and error routine.

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:The problem with patterns

[SirSlud]

Good point!

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:The problem with patterns

[be-fan]

I have a copy sitting at home :) I agree that its a great book, but it really highlights for me how much C++'s template mechanism blows. Those techniques are nice, but they're unusable in real code. Have you ever tried to trace through a compiler error resulting from a typo when using Loki or some of the more esoteric Boost libraries? They're unreadable! A small typo in a lambda expression that would cause a single error message in a Lisp compiler becomes several screenfuls of tracing through a template expansion. Worse, the error locator never gives you the right line number, because of the way the template expansion works. To top it all off, there is no C++ equivalent of Lisp's MACROEXPAND, so you can't see what a template trick will expand to without writing it out on paper.

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:An Excellent Book-Plus one

[under_score]

Cool - thanks for what I'll take as recommended reading! Always looking for new books to consume, internalize and act upon.

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:Christopher Alexander: The true originator?

[russellh]

yes, alexander is the originator. he is a berkeley professor of architecture. he was honored at OOPSLA in.. 1998? 1997? for his work. richard p gabriel has a good overview of alexandrian patterns wrt software in his book patterns of software (which Alexander intro'd).

However, in my view - and at least a few others - the pattern concept as understood by software people is generally neutered. alexander focuses on the process; patterns are nearly worthless without the generative way in which one employs a pattern language. It's how, not what, which is why the first volume of the one you mentioned is called the timeless way of building. But I will say that it is not obvious how his concepts translate to software at all. for instance, there is no software architecture/design that moves us like, say, the Notre Dame cathedral does; it just doesn't make sense. I'm not moved by anything in the GoF book the way I am by A Pattern Language, despite being a severe programming geek. And I mean not even remotely. The GoF book, while full of fun and useful knowledge, leaves one cold. Perhaps this notion of pattern is all we can do thus far, without the software equivalent of the way.

Finally, Just a few years ago Alexander published his massive 4-volume book, The Nature of Order that he'd been working on for 15 years or so. Required reading.

Re:Christopher Alexander: The true originator?

[dudeman2]

Yes. He's cited as an inspiration for software design patterns. He's an actual architect.

Give it to Code Complete, instead...

[javabandit]

Seriously. I think some patterns are fine for some things, but as a previous poster has stated, more ugly-as-shit code has been written using design patterns than not.

I know that in the OO languages world, this book is hailed by many as the holy book, but to me, there really is only one... "Code Complete".

The one book teaches the fundamentals of good programming *in any language* better than any programming book ever written.

Case in point, I don't think any shit code has been written as a result of applying the techniques and best practices in "Code Complete". I certainly can't say the same about "Design Patterns".

Re:Design Patterns are Band Aids for OO programmin

[MobyTurbo]

For another take on design patterns, I consider them to be nothing more than tricks to get around the braindead limitations of most mainstream object oriented languages. Its no accident that non object oriented languages like Lisp and ML don't have quite so many design patterns.

What do you mean Lisp doesn't have object oriented features? Have you heard of CLOS, built into Common Lisp? (CLOS is even older than C++, CLOS was the first OO extention of a mainstream language.)

Even Paul Graham, a Lisper critic of object oriented programming, creates his own set of object oriented systems in the final tutorial chapter of his book, "ANSI Common Lisp". (It's easy to build object systems in any language, such as Common LISP or Scheme, which have lambda and lexical scope.)

As for ML, the most popular ML language is OCAML. The "O" in OCAML stands for "objective", guess what that means. It's no wonder you posted as an AC, you obviously don't know anything about Lisp or ML other than what you've read in someones' blog.

Re:Design Patterns are Band Aids for OO programmin

[IkeTo]

> I consider them to be nothing more than
> tricks to get around the braindead
> limitations of most mainstream object
> oriented languages

This is a perfectly right comment. For example, if your language supports closure, your need of the command pattern is greatly reduced. If you use a dynamic language like Perl or Python, you will find many patterns like bridges and abstract factories completely useless.

That said, each language has its own set of limitation. Before some genius creates a language that has everything we want (and still has the language comprehensible), we will continue to need some "band aid". If we need band aids, it is probably better to have a standard band aid for each purpose, rather than having a different one each time for no reason.

Your advice came too late for me

[some guy I know]

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.

I fully expected design patterns to solve all of the problems in the world, and was surprised when they didn't.
Hunger still exists.
War still exists.
Republicans and Democrats still exist.
Design patterns have not solved these and other problems, to my complete and utter surprise.
(Hitler doesn't exist any more, but I don't know how much design patterns had to do with that.)
Had I read your post earlier, my surprise might have been alleviated, or perhaps avoided altogether.

If your post can prevent one person from being surprised when design patterns don't solve all of the problems in the world, then I would say that it was worth all of the extensive effort that you obviously put into it.
You, sir (or madam), are a sage.

Or something.

Re:let me second that

[rpdillon]

A great man I work for says "Well, you can always design software badly."

It doesn't seem like much on the surface, but he strikes at the heart of statements like yours. No matter wat you do to your language, you cannot systematically replace discipline with procedure. In this case, you are basically blaming the language for the need to learn design patterns. But really, no language will free you from having to learn how to program in the correct way.

Another mentor of mine told me that design patterns in object oriented programming try to imitate aspect oriented programming, and I think he is right. But that still doesn't change anything: you can still scrrew up in aspect oriented languages (*especially* in aspect oriented languages!).

Anyway, it is interesting that you demean the book...I think if more software designers understood design patterns, the world would be better place, at least with repect to the state of the art in computer programming. There is a lot to be said for proving a pattern to be effective at solving a problem once, and them implementing it many times, relieving its implementors of having to prove again and again its validity. Design patterns allow you to merely prove that you implemented the pattern correctly; you can stand on the shoulders of giants and allow those that created the pattern to prove it's validity.

Is it depressing, as you say? I don't think so...it is par for the course. Object oriented programming is very important, but was only picked up en masse in the 1990's, 30-40 years after it was developed. The fact that this book has been picked up and recognized as important a mere 10 (give or take) years after its publication is heartening. Sometimes the importance of a work is not apprent immediately, and so it was in this case, at least to some.

Others, well, at BBN every new programmer was given a copy when he or she was hired. I wasn't so fortunate at my company, but I was nevertheless encouraged to read and understand the ideas in GoF. A copy sits next to my keyboard, and I read it nearly everyday. I think it is quite deserving of the award.

Do nearly all programmers just do User Interfaces?

[threaded]

These pattern things are all well and good. Yet they only seem to crop up in user interfaces. When it comes to doing proper programming, i.e. solving the customer problem, there are more important considerations, such as seeing if the customer's problem fits in the four steps of a church-turing thesis, or if a coin is tossed somewhere along the line.

Re:Design Patterns are Band Aids for OO programmin

[loqi]

If we need band aids, it is probably better to have a standard band aid for each purpose, rather than having a different one each time for no reason.

But this is exactly the point. High-level abstractions are fantastic, but there will always be a need for, if nothing else, alternate implementations of those abstractions. As long as we still need a language sitting where C++ sits relative to the hardware, we'll need these elegant solutions to the "braindead limitations" of lower-level languages.

Re:let me second that

[cahiha]

Is it depressing, as you say? I don't think so...it is par for the course.

Software development was governed by design patterns long before the GoF wrote their book. What is depressing is that (1) people like you think these people actually invented patterns, (2) you didn't figure it out for yourself before picking up the book, (3) most of the actual patterns in that book are workarounds for limitations of current OOLs, and (4) people like you think that all of that is really just fine. It's the blind (GoF) leading the blind (people like you).

I think if more software designers understood design patterns, the world would be better place, at least with repect to the state of the art in computer programming.

Perhaps a better approach would be to simply fire people who need books to figure this stuff out.

Boring book apart from first 50 pages

[waveman]

The first 50 pages of generic design recommendations are not too bad but the patterns themselves are very boring to read.

There seems to be a strain of pedantry that is attracted to OO programming and it is in full flight in this book which is full of tedious repetition. As has been pointed out elsewhere, too many patterns can be a bad thing, a very bad thing. Also, patterns are in a way an admission that the language is flawed. You should not have an iterator pattern - you should have an iterator macro! Why are we still coding in low level 3GLs like Java 47 years after FORTRAN was invented?

I find the anti-patterns books more interesting. Why do people build spaghetti trash and what can you do about it? The answers are out there.

Re:Boring book apart from first 50 pages

[Viol8]

"Why are we still coding in low level 3GLs like Java 47 years after FORTRAN was invented?"

Quite. And why do we still have wheels on vehicles 10,000 years after the wheel was invented? Surely someone could have come up with something better by now!

Agree with you about patterns tho.

We need more books on the same subject

[beforewisdom]

That book needed more examples.

Granted, I read it recovering from surgery with anesthesia in my system, but I found it to be prohibitively dense material for concepts that don't warrant that density.

The contribution to programming from those concepts will be fully realized when they are expressed in a form easily digestible by busy programmers who have to do a lot in the real world.

Design patterns - the emporers latest new clothes

[Viol8]

With all the hype over design patterns (usually by OO zealots who couldn't code in any other paradigm if their lives depended on it) you'd think no one had managed to write complex systems before they came along. In fact it seems to me that since the false prophet known as OO with all its attendant accolytes came along (design patterns being one of them) programming has actually got harder, less efficient and far more costly.

IMO its time to ditch all this high level buzzword trash coding methodology and go back to something a bit lower level whereby coders actually have to put some thought into what their writing and hopefully produce a fast , efficient end result. Not just use someone elses lego bricks to build some bloatware system thats has all the stability and robustness of a 1 legged stool. Far too many clueless idiots are coders these days. Its a bit like car maintenance - you have the people who can change the oil and air filter and plug in a new alternator out of a parts box and then call themselves mechanics , but the real mechanics know otherwise.

Re:let me second that

[Tim Browse]

Perhaps a better approach would be to simply fire people who need books to figure this stuff out.

Awesome plan. While we're at it, let's get rid of all the books too. Documentation is a crutch as well, so let's delete all that. And burn down the universities - no-one ever gained anything from them that they couldn't have figured out in their own lifetime.

Also, no-one should be allowed to pass on advice, because everyone should be able to work this shit out for themselves.

"I read constantly to gain new knowledge and insights. Why spend years of learning by trial and error when I can pickup a good book and in a few days achieve insights that took someone else decades to formulate?"

-- Steve Maguire, "Debugging The Development Process"

Re:Design patterns - the emporers latest new cloth

[osi79]

> Not just use someone elses lego bricks to build > some bloatware system thats has all the > stability and robustness of a 1 legged stool. So you say a system built of "your own sandcorns" is more stable than using "someone elses lego bricks"? Lego bricks being available as libraries are mostly better tested (more eyes) than the stuff you coded for your own. Just look at the security problems with C: Because most C coders have to play with char arrays for string handling instead of using a string class, we have all these buffer overflows all the time. Using a string class that abstracts from the nasty details makes the code less error-prone and more secure. A common string class gets more code review than your own privately used code will ever get. Also, abstractions make the code less complex and thus improve code quality. > Its a bit like car maintenance No, its more like building skyscrapers. Nobody would build them out of sandcorns at the building site. You use components.

Patterns good, wannabes bad.

[dwalsh]

Several people here have commented on how they have seen misuse of design patterns in code, or that a high usage correlates with bad code. This can happen, and I will discuss what I have noticed, but this does not reflect on the Gang of Four, or their book.

The book discusses the symptoms which would cause you to consider a particular pattern, and the disadvantages of using said pattern. In general, most of the patterns reduce coupling, and the flipside of that is it harder to follow the code - coupling means you can jump straight to where something is implemented. You use the pattern where you know without it e.g. the number of branches or classes has grown, or definetly will grow, to be unmanageable.

Design patterns became very fashionable, so everyone wanted to show they were using them. This meant that people who did not understand (or care about) the justification and negative consequences using them where the current and future requirements were simple, and the simple non-pattern solution was manageable.

For example, dozens of utility classes done as factory pattern. Therefore there is an interface and a factory, but there was only one implementation class needed and created. That class typically had a few extra methods, so client classes downcast to the concrete class. Pointless. It also made it harder to find what a framework method did, as you had to see what the factory was configured to create to find the implementation.

I have been in the situation where a poser at a design review insisted on using the strategy pattern because there was an if-else in my code (i.e. exactly two branches and the requirements were fixed). If someone like that gets their way, the code becomes very unreadable, inefficient and over-engineered.

People also cite that you can use the name of a design pattern, and other OO developers will understand this complicated design feature because it maps to the pattern. That is o.k. but the wannabes put the name of a pattern on their own solution which is quite different. Their solution might be valid, but they put a misleading name on it to get the pattern halo effect.

If some one reads the considerations mentioned in the book, and uses the pattern where there is a lot of complexity, or you can predict there will be a lot of complexity, they are an excellent solution to OO design problems that arise again and again.

A little from column A, a little from B

[Vengeance]

I would say that 'Design Patterns' is at least as much descriptive as prescriptive, in that they are describing what's been found in software 'in the wild' so to speak. Each pattern includes examples of where they've been found. In addition, each pattern includes a list of pros and cons.

I generally find that I prefer to let my code dictate my patterns, rather than the other way around. When building a system which calls for a centralized menu (or command line) to invoke various procedures, it's generally a good idea to see what the book has to say about the 'Command' pattern, and at least see what pitfalls one might encounter, and what kind of best practices have been discovered.

Re:Design Patterns are Band Aids for OO programmin

[Ender_Stonebender]

Agreed. Trying to use a design pattern that is close, but not quite, what you need, is like trying to fit a square peg into a round hole: It may work if you use a big enough hammer, but it's never going to be as good as just using a round peg.

Everyone: Please ignore this book, and actually solve the problems you have; rather than attempting to look up the answer in this "solutions manual" for writing programs.

--Ender

Re:Do nearly all programmers just do User Interfac

[bmac]

Actually, I find that each user interface (aside from simple dialog boxes) is unique enough that it would really be its own pattern, though as I move towards creating a suite of software tools, my general user interface style will emerge as a rather complex pattern. But before I can do that I have to have many hand-coded instances first so that I can factor out the pattern.

I find patterns most useful in three specific areas: container/list class design, database design and database to class mapping.

I wrote a tool to generate c# classes that wrap the ArrayList class with functions that return a properly-typed elements. It's basically a c++-style template creator (with lots more parameters), yet what it really is is a pattern definition and instantiation process. I define the instance parameters (like includeStackRoutines? and elemHasName) and then I generate a list container. It takes two minutes to generate the class, and this is all because of patterns.

The second use of patterns is in database design, or, rather, the definition of the tables within the db. Some tables have a unique id, some have versioned records, some have another table in a 1:n relation, etc... Even in a large (in my professional experience) db, the types of relations between tables is usually relatively small in number: maybe four or five. Each set of SQL statements that access a section of the db will be just like the SQL statements used for other sections that have the same type of relation, which is a pattern. (BTW, I don't use stored procedures because there are completely non-portable and have lousy error reporting, IME. I do, however, love the idea of having such a clean interface to my db.)

The third situation is in mapping the db structure to a class structure. Once again, similar design patterns for the tables lead to similar patterns of class implementation.

Remember that with patterns what someone else in this discussion said: if the code was exactly the same it would just become a single function. The point of patterns is to factor out the commonality of code and to then apply the pattern as a framework for the creation of similar pieces of code. The key here is that the other areas are
*similar*, not the same.

A very simple example that I'm dealing with now is that I'm rolling my own scroll bars within a generic canvas. The code for the vertical click-and-drag bar is the same pattern as the horizontal bar, except that .y becomes .x. All I'm doing is getting the vertical bar correct (which is quite a bit of a pain, actually), then I'll apply the pattern to the hor bar. This is a very simplistic yet completely realistic example.

Peace & Blessings,
bmac

Re:MOD PARENT UP

[EastCoastSurfer]

What is bullshit about the idea of design patterns? The book contains examples of 23 design patterns that the authors have seen. By no means are they the end all of all patterns. You could even argue (and the authors would probably agree) that there have been some better solutions found to the design problems posed in the book.

The main idea of the book is that there are common design problems that people run into over and over in software. A pattern is simply a proven solution to those problems.

However, in the real world, where customers want their software to run fast and use a minimum amount of system memory, these techniques, while instructive, are ultimately utterly worthless.

In the real world customers also want their software delivered in a timely manner. By recognizing common patters in a software design problem it allows the engineer to get to the unique problems more quickly.

What's funny is that you don't like the book, but if you are any good at software engineering you're already using patterns everyday. IE, you've seen this design problem before and this is how you solved it last time.

Think beyond just what's listed in the book and think about the ideas that were presented. Apply that thinking on a larger scale where you don't personally have to see and solve every design problem and then you can understand the usefullness of design patterns.

Re:let me second that

[rpdillon]

Software development was governed by design patterns long before the GoF wrote their book.

Really? Where? Because software design patterns are not present (even OO programming isn't present) in the vast majoity of code written in 1995.

What makes a pattern important is that it is widely recognized - it allows not only for reusable code, but more importantly, reusable thinking. Others can pick up your code and see what patterns you used, which allows for a sort of instant comprehension. It also allows you to frame other programming problems in familiar terms, allowing for you to carry thinking over from problem to problem, speeding development.

(1) people like you think these people actually invented patterns

Actually, I don't. If I had to give credit to someone, it'd probably be Kent Beck and Ward Cunningham (of wiki fame) who did their work in the late 1980's. That doesn't mean that they made patterns popular though. The GoF made great strides to make their work usuable by identifying 23 patterns that were oft used.

(2) you didn't figure it out for yourself before picking up the book

I apologize. I am not as gifted as some in these areas.

(3) most of the actual patterns in that book are workarounds for limitations of current OOLs

A criticism often leveled at design patterns. Perhaps valid, but it doesn't change the fact that the patterns are needed, given the "limitations of current OOLs".

(4) people like you think that all of that is really just fine. It's the blind (GoF) leading the blind (people like you).

I don't think it is fine. I think it is great. What is currently cutting edge becomes mundane in 50 years. Calculus was at one time very advanced, and only the most educated understood it. I think it is an advancement that most everyone knows calculus today. Similarly, I think it is progress to have GoF broadly understood. This is usually best accomplished by writing a book that people can read about the subject, and GoF did us that courtesy. Again, I think they are quite deserving of the award.

Complete Construction

[Gorimek]

Why would size be a changeable property in the first place? In geometry, objects certainly don't change size once they exist. If yours do, you're doing some kind of animation, and probably have no use for squares anyway.

Perhaps the pattern missing here is Complete Construction. If some property is unchangeable, it should be set at construction time, and never be changed. The class interface needs to reflect this, so in this case we would have a Square constructor taking one argument, a Rectangle constructor taking two arguments, and no setSize() method.

Inheritance is overused by people who don't know what they're doing, but the same can be said about the inheritance backlash. I meet many developers who avoid inheritance, but few who can explain why and when.

Re:Design Patterns are Band Aids for OO programmin

[AveryT]

Design Patterns are not mean to be "ccokie-cutter" solutions. They will not make a bad programmer produce good code.

A Flyweight class used to represent individual characters in a document (as suggested in GoF book) will look very different from one used to represent individual frames in a video clip (as implemented by me after reading GoF book.)

Design Patterns provide a framework for thinking and communicating about the design space for a particular problem but they are no substitute for rigorous thought, problem-solving skills, and good design principles. These you must bring to the table yourself.

Re:let me second that

[cahiha]

Awesome plan. While we're at it, let's get rid of all the books too. Documentation is a crutch as well, so let's delete all that. And burn down the universities - no-one ever gained anything from them that they couldn't have figured out in their own lifetime.

That's not what I said. What I said is that this specific concept is so simple that if it wasn't obvious to a working programmer, they have no business being in the business.

Also, no-one should be allowed to pass on advice, because everyone should be able to work this shit out for themselves.

Generally, it is good for people to work things out for themselves. Often, in education, we have to short circuit that in the interest of time. But there are many things that, if you couldn't have worked them out for yourselves, you shouldn't be in the business at all.

The trouble with people like you and Maguire is that you think that it all comes down to education, documentation, and discipline. But those educational tools only let you produce the programming equivalent of short order cooks, which is why software sucks so badly.

Re:let me second that

[cahiha]

What makes a pattern important is that it is widely recognized - it allows not only for reusable code, but more importantly, reusable thinking.

Yes, patterns are important, and it is important that they are widely recognized. That's why many languages have them built in. Hence, the ancestral comment that most of those patterns aren't needed in Lisp. But instead of telling you to use the correct tools for the job, the GoF book amounts to "structured programming in Fortran 77" or "object oriented programming in assembly language".

Similarly, I think it is progress to have GoF broadly understood. This is usually best accomplished by writing a book that people can read about the subject, and GoF did us that courtesy.

I think it is merely symptomatic that the GoF book even had to be written: it shows that the industry is based on the wrong kinds of programmers, the wrong approaches, and the wrong tools. The book may well help improve software development slightly in the short term, but it doesn't represent progress towards solving the fundamental problems with software development.

What is currently cutting edge becomes mundane in 50 years. Calculus was at one time very advanced, and only the most educated understood it

My prediction is that, unlike calculus, design patterns and OOP will not stand the test of time. After an initial blossoming of creativity in the middle of the last century, we are in the dark ages of software engineering right now, complete with the inquisition, crusades, and black death. A century from now, people will look back on OOP and design patterns and think of them as being as ridiculous as Ptolemy's epicycles.

Inheritance=extend interfaces,not implementations

[master_p]

The problem with today's OO programmers is that they don't know this simple principle: inheritance should be on extending interfaces, not implementations.

An example of the above principle is a common mistake of GUI toolkits: there are widget classes that inherit from a 'Window' class, simply because the widget uses a native O/S window to display its output. If the toolkit is transferred to another O/S which does not have windows (for example, an OpenGL implementation that uses texture composition), then the toolkit falls flat on its face.

Some patterns don't even have good implementations

[Latent Heat]

Sometimes I wonder if what we are doing with objects is a version of Greenspun's 10th law -- that every (language X) program is a buggy, incomplete reimplementation of Common Lisp.

Some of the patterns don't seem to have good implementations. Take Singleton, please! It gets hard to implement the one-and-only one instance of an object and in a non GC language to enforce that it gets deleted correctly at the end. Are there any clean implementations of Singleton in any of the regular OO languages?

I am all for identifying the patterns and extending languages to simplify their implementation -- otherwise you are spinning your wheels trying to rewrite the same (potentially buggy) code all the time.

Re: cdr and strings in LISP

[some guy I know]

Yes it can [point to an arbitrary memory location (such as into the middle of a string)], since strings in lisp are sequences, and you can easily point to their cdr which might be in the middle of the string.

Strings in LISP are sequences, but they aren't lists, at least, not in Common LISP.
In Common LISP, they are one-dimensional arrays (character vectors).
As such, a cdr can't point into the middle of a string, since cdr can't point to a subsequence of an array.
In fact, the only thing that you can do with a substring as a whole in CL is make a copy of it and replace it.
(It's possible that some CL implementations allow other operations, and it's possible that other LISP dialects (e.g., Scheme) may allow other operations, but those are not Common LISP.)

Re: External Libraries

[some guy I know]

One thing that I've learned about Lisp is that the distinction between "library" and "language" is pretty meaningless.

What I meant by external library was a library that isn't considered part of the language, or isn't used to implement part of the language.
For example, versions of C on machines that don't support floating-point (e.g., PDP-11) usually call support library routines to do floating-point operations.
I consider such routines to be part of the language implementation, and thus I consider floating point operations to be part of the C language, even when the underlying code calls library functions.
OTOH, to do I/O, a C program has to explicitly call functions such as printf, etc., so I/O is not part of the (ANSI) C language itself; i.e., C can't do I/O without calling (functions in) an external library (even if some compilers recognize functions like printf and can optimize it to a call to puts in some cases).
(This may have changed with C99; I haven't had a chance to look at the C99 spec yet.)

Similarly, it is irrelevant (except maybe in terms of performance, low-level debugging, etc.) whether a particular CL implementation uses a macro, function, or a single opcode in its built-in VM, to implement a particular operation that is part of the language (as long as it conforms to the spec).
I consider such lower-level macros/functions to be part of the implementation, built-in, internal.
OTOH, something like an interface to the sockets library I consider to be a reference to an external library, even though you use operations in such a libarary the same way you do the "built-in" operations, once the package as been loaded (and its symbols have been interned).

Re: FFI: With FFI, you can interface to just about anything.
It's just that if you want that "anything" to do the things that I mentioned earlier, then it will have to be written in a language other than (Common) LISP.
In addition, IIRC, FFI is an extension to CL, not part of the "standard" language, and may be implemented by different, uh, implementations in different ways.

Rereading the above, I can see that I am not expressing my position as clearly as I'd like to.
Still, I hope that you can get the jist of it.

Even if you win...

[heinousjay]

You can drive screws with a hammer if you want to. Hell, you can even try to saw a board with it. That doesn't mean the hammer is a flawed tool.

Arguing on the internet, special olympics, blah blah blah. I just won't get into it, sorry. You obviously hold more of an emotional stake in this than I do.

Re:Even if you win...

[syousef]

You can drive screws with a hammer if you want to.

How about you stop trying to screw me for a start by making out that my arguements aren't well thought out when you refuse to "get into it". What the hell does the special olympics have to do with anything?

Do everyone a favour and take a deep breath.

It's good but don't forget :-)

[ooo00ooo]

It's good for them, they bring together in that book some good stuff ! But we often forget some old folks too, let remember good old days of Smalltalk-80 form Xerox ( and of course Smalltalk 72 ) the real first metaclasse based OO language where you can find alot of those (new) paterns. ( no Bill didn't invent OO ! ) http://www.archive.org/details/DanIngal1989 All of other languages have some interest patern too, let just think at CSP-Occam, Scheme(kindof lisp) ... :-)

Re:let me second that

[AuMatar]

TO be fair- design patterns existed prior to 1995. In fact, they existed prior to OO programming (99% of the patterns in DP can be applied to procedural coding as well). What the GoF did wasn't to create the patterns, but to identify them and push the concept of patterns as a means of communication between programmers. Of course, that work alone is probably worthy of the award.