Ted Neward has posted a O'Reilly weblog in which he responds to Alan Williamson's JDJ Design Pattern Snobs article by defining design patterns and discussing their utility.
I don't want to seem like I'm bashing Alan or his level of expertise or experience. It's an absolute truth that some have held the idea of patterns as a hatchet over people's heads for some time now, leading many to believe that patterns are this mystical cult or exclusive club that only those born with the right birthmark can get into. I've met several of those design patterns snobs, and he's right: they just make your skin crawl with their condescending attitudes and lip-curling sneers of disdain. When I find one, I usually take great delight in drilling him on the excrutiating details of pattern after pattern after pattern. :-) Of course, I've also met my share of EJB snobs, COM+ snobs, and even container-classes snobs ("We wrote our own, HIGHLY-tuned, HIGHLY-efficient set of collection classes, and it only took us two years to do it....."). Snobs in general suck.
What truly makes this story worse, however, was that just as the patterns world was starting to build some critical mass, the marketing folks got hold of the name, and diluted the idea of what a pattern was back into "code reusability". Worse yet, patterns began to be misused and misinterpreted--quite probably the worst offender here was Sun, with their "design patterns" in JavaBeans (sorry, guys, using get/set method names to define a property isn't a pattern) and their "Model-View-Controller" pattern in JSP/servlets[1].
As a result, expectations that patterns would cut development time by outrageous percentages were set, and since patterns really had little to do with development time (patterns influence design time, not development/implementation), the expectations weren't met and yet another interesting thing in Computer Science fell by the wayside. Today, patterns are relegated to the dustbin of "passe technologies". Mention that you're interested in using patterns or use a pattern by name as part of your discussion, and suddenly you're a "design pattern snob".
I though Ted Neward did a good job of explaining what design patterns are and how they are helpful. What surprised me was the statement:
Today, patterns are relegated to the dustbin of "passe technologies".
I hadn't realized. I thought design patterns were still enjoying their buzzword status. What is your opinion of design patterns these days?
This had me reaching for the dictionary straight away and in vain, too. My copy of the Oxford English Dictionary doesn't contain the word tuple (I'm guessing tuple=collection). Having read further through the article Ted does say a lot of good stuff, however, I think that that opening phrase unwittingly vindicates a great deal of Alan's original rant.
I had a programmer with a lot of experience in procedural programming, but without any exposure to Object Oriented code. Rather than try to sit down and communicate the various underlying theories of OO programming (contrasted with the sort of thinking he was used to) I passed him a copy of the Gang of Four book. It worked very well indeed, and the zen that the article talks about really was transferred.
In my eyes the real win that patterns give us is the ability to convey experience. Possibly the best book of patterns I've read is Kent Beck's 'Best Practice Patterns'. It conveys an astonishing amount of wisdom from years of programming experience, and it does it using patterns in a way that is simple to read and understand.
No great insight perhaps, but my point here is that there is use in Design Patterns beyond the hype, just as Java has proved to be a useful tool, just as XML has proved to be a useful tool, just as many other future buzzwords will. There can be no doubt that often a buzzword is just that. Other times however, the particular idea behind the buzzword really is useful, and it would be foolish to reject it simply because of the hype.
> No great insight perhaps, but my point here is that there > is use in Design Patterns beyond the hype, just as Java > has proved to be a useful tool, just as XML has proved to > be a useful tool, just as many other future buzzwords > will. There can be no doubt that often a buzzword is just > that. Other times however, the particular idea behind the > buzzword really is useful, and it would be foolish to > reject it simply because of the hype.
I don't quite equate "hype" and "buzzword." I think of hype as hoopla generated by proponents of a technology (or methodology, idea, etc.). Hype is kind of marketing that includes making grandiose claims that probably won't ever be true to stimulate people to talk about the technology So I see hype as something coming from the producer of a technology
Buzzwords, on the other hand, are something that developers as consumers of technology latch onto and get excited about. Their excitement is often out of proportion with the actual promise of the technology. I see buzzwords as something that really arises from consumers of technology.
Neither hype nor buzzword status indicate a technology have no merit or utility. Usually the technology is very useful, just not quite as useful as the hype or buzz promises. The thing I'm wondering about why developers as a group seem a bit overly disposed to latch onto buzzwords.
> I don't quite equate "hype" and "buzzword." I think of > hype as hoopla generated by proponents of a technology (or > methodology, idea, etc.). Hype is kind of marketing that > includes making grandiose claims that probably won't ever > be true to stimulate people to talk about the technology > So I see hype as something coming from the producer of a > technology > > Buzzwords, on the other hand, are something that > developers as consumers of technology latch onto and get > excited about. Their excitement is often out of proportion > with the actual promise of the technology. I see buzzwords > as something that really arises from consumers of > technology.
I agree that that buzzwords != hype, but producers of a technology hype it in order to generate a reaction amongst consumers of a technology which will create 'buzzword' status.
> Neither hype nor buzzword status indicate a technology > have no merit or utility. Usually the technology is very > useful, just not quite as useful as the hype or buzz > promises. The thing I'm wondering about why developers as > a group seem a bit overly disposed to latch onto > buzzwords.
I'm not sure its entirely developers at fault here. The team I currently work with tend to be quite cynical about both buzzwords and hype. For example any mention of XML around the technical end of the office tends to bring up complaints about angle brackets and character set encodings rather than augeries of One True data exchange format.
I'm not sure this is true for all development teams however, and I think experience tends to account for a lot. A lot of developers that have been trained over the last 2 years have gone through intensified 'Learn to Program in 21 days' courses that have created more than a little of the buzzworditis you talk about. More experienced developers, I'm sure, have a cynisism that tends to insulate them from this, possibly because they have experienced it so many times in the past.
I haven't read the articles yet, but wanted to go ahead and chime in on the question of what I think of patterns today. I think they are absolutely invaluable because they convey good design. The example given by James in his original post is a great example of this. In fact, I was surprised at a recectn Atlanta JUG meeting when Mark Fleury proclaimed that "patterns are worthless and no substitute for a good Java classes". I'm thinking, this guy is obviously very intelligent and surely a gifted software engineer. How could he miss the obvious benefit? These are examples of "good Java classes".
The interview with Richard Gabriel on "The Poetry of Programming":
> Fleury proclaimed that "patterns are worthless and no > substitute for a good Java classes". I'm thinking, this > guy is obviously very intelligent and surely a gifted > software engineer. How could he miss the obvious benefit? > These are examples of "good Java classes".
I often use a jigsaw puzzle example when I explain how patterns work to people who've not encountered them before.
If you have a jigsaw puzzle with over say, 50 pieces, you need a strategy to solve it. I tell you to put the edges together first, and that will help. Lo, it does.
This isn't a surefire solution or an algorithm. Its a generic solution. It conveys my experience of putting jigsaw puzzles together to someone who has never put a jigsaw puzzle together. It doesn't claim to be The One True Way. It claims to assist. It is (ta-da!) a pattern.
Patterns are not just about software, classes, or java. They exist for better or worse in all levels of things we do - but yes, in many cases examples of good java classes can be found in pattern books. On that basis I will continue :-)
A class exists to fulfill a requirement. It will have a design, which is created either explicitly or implicitly[0]. Either way it will have had some thinking behind it that will have influenced its 'shape'. This thinking will be influenced by the thinkers' experiences by drawing comparisons between things that have happened when doing something similar to what is being attempted now.
If you could extract those experiences into a formal notation you'd probably have something a lot like patterns. You could look at patterns as a step in the 'industrialization' of software.
James.
[0] either way is good, having a design 'fall out' of the software can lead to the best designs IMO. But that would probably be better stated in a refactoring discussion :-)
Previous Topic
