These books are basically the equivalent of a zoologist going out into the world of existing code bases, and trying to come up with a naming scheme for everything they find. Most of the OO patterns existed long before the Gang of Four formalised them. Many of them existed before we even had commercial OO languages. And I'm certain most of the patterns in this book have been used (where suitable) by web developers for a long time now. It can be useful to have some terms defined, but in the end you either have the mentality and skills to make easy to maintain, robust software, or you are a manager.
The point is to take a bunch of individuals' knowledge and experience and combine them into something greater and consumable by the inexperienced. There's much lost in the translation, and the dangers of cargo-culting is well-known, but that's the purpose of digging into patterns.
Translation: taxonifying the patterns makes them teachable. It's why Aristotle wrote about poetics, why Linnaeus classified animals, etc. Organizing and systematizing knowledge makes it a teachable art. This is as it was in ancient Greece, Rome, medieval Europe, the Renaissance, the Enlightenment, the modern era: as it always was and shall be.
Of course, some programmers parenthetically remark that rather than being "a general repeatable solution to a commonly occurring problem in software design", a design pattern is more of a symptom of inadequacy in the programming language in question.;)
Or a symptom of inadequacy in the skills of developers. Better to give them a cookbook with recipes they can cut-and-paste without understanding why - and because the recipe is in a book, it's valid - right ?
I think the reasoning is that even a skilled developer would be doing things (for want of a proper language construct) in the same repetitive way, he merely wouldn't have to be told so.
I like your zoology analogy. I would like to add that naming things is useful and important.
Years ago, I presented a 5-10 page design for a software component to my manager and the company architect. I had a nice document with diagrams and all that. After about 10 minutes in the meeting of presenting some stuff, the architect patiently said something like "So you plan on using a builder pattern, using chain of responsibility to dispatch the events. Sounds good, go for it!" He called for the meeting to
The decision doesn't have to be logical; it was unanimous.
Zoology for programmers (Score:4, Insightful)
Re: (Score:3)
The point is to take a bunch of individuals' knowledge and experience and combine them into something greater and consumable by the inexperienced. There's much lost in the translation, and the dangers of cargo-culting is well-known, but that's the purpose of digging into patterns.
Re: Zoology for programmers (Score:0)
Translation: taxonifying the patterns makes them teachable. It's why Aristotle wrote about poetics, why Linnaeus classified animals, etc. Organizing and systematizing knowledge makes it a teachable art. This is as it was in ancient Greece, Rome, medieval Europe, the Renaissance, the Enlightenment, the modern era: as it always was and shall be.
Re: (Score:3)
Re: (Score:0)
Or a symptom of inadequacy in the skills of developers. Better to give them a cookbook with recipes they can cut-and-paste without understanding why - and because the recipe is in a book, it's valid - right ?
Re: (Score:2)
Re: (Score:0)
As if your comments makes sense? Not! At! All!
Re: (Score:2)
I like your zoology analogy. I would like to add that naming things is useful and important.
Years ago, I presented a 5-10 page design for a software component to my manager and the company architect. I had a nice document with diagrams and all that. After about 10 minutes in the meeting of presenting some stuff, the architect patiently said something like "So you plan on using a builder pattern, using chain of responsibility to dispatch the events. Sounds good, go for it!" He called for the meeting to