doing TODAY and not getting caught in the HYPE of tomorrow

Alan Williamson

Subscribe to Alan Williamson: eMailAlertsEmail Alerts
Get Alan Williamson: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Design Pattern Snobs

Design Pattern Snobs

Have you noticed lately how the word pattern seems to be creeping into general musings and dialogue more and more? Like name-dropping, it's consciously woven into the fabric of the conversation as a way to assert a certain level of understanding and credibility. Mention the latest design pattern and suddenly your peers will see you as a genius of software engineering, " see I have employed the Decorator pattern for this particular class..." While you're fighting the urge to give them a good slap, allow me to let you into the big secret. There is none!

When perusing various article submissions for our beloved magazine, I am constantly surprised to see how laden down with buzzwords the proposals are, as if vainly attempting to show off their superior knowledge by dazzling our editors with fancy acronyms and big words. I had an exchange with one potential author, who I would class as the typical design-pattern snob. I'm sure you've come across them at some point. They're the ones who love using this terminology, and chastise anyone who doesn't understand or uses an unofficial pattern.

To that end I had to do something ­ I had reached the saturation point. Although I am a young fellow, I have to hold my hand up and say I was educated in an era before design patterns were even invented. Yes, it's true, such a time did exist. In my day they were called data structures. Now admittedly, this doesn't sound half as sexy as design patterns, but they were the exact same thing without today's buzzwords.

To all those developers who are getting frustrated with the constant use of the word patterns, and who feel they may be missing out on some great new movement, I say to you: don't panic. They're just repackaging the stuff you've been doing for years in a format that can be openly discussed. For example, the class you designed that can have only one instance created ­ in the pattern world, this would be known as a Singleton class. Easy, eh? Not shrouded in as much mystery now. A design pattern does not specify any code, nor does it even specify a template, merely a way of doing something. A pattern!

The next time you get into a discussion on design patterns, be it at an interview or over the water cooler, stay calm, and merely ask the offender to explain what exactly he or she means. I would guess that 9 times out of 10 you've used it many times and didn't even realize you were a design pattern follower!

.  .  .

Last month I highlighted how delighted I was with a great client-side technology,, and how it was a wonderful example of how Java, in the right hands, can really rock. This month I have found another. It's not a tool for Java developers, however; it's more for the masses. Check out, a lightweight Java audio tool for listening to streaming MP3 and Ogg files inside your browser. It works very well, and Kendal, the man behind it, has put a lot of effort into writing his own libraries to ensure that they're small, as opposed to using some of the bloated official Java APIs. Yet another shining example in which small can be beautiful, and creativity and engineering can prove that Java is still the only one to win against Flash and other plug-in technologies.

Keep up the good work, people. We are proud of you. Your community needs you.

More Stories By Alan Williamson

Alan Williamson is widely recognized as an early expert on Cloud Computing, he is Co-Founder of aw2.0 Ltd, a software company specializing in deploying software solutions within Cloud networks. Alan is a Sun Java Champion and creator of OpenBlueDragon (an open source Java CFML runtime engine). With many books, articles and speaking engagements under his belt, Alan likes to talk passionately about what can be done TODAY and not get caught up in the marketing hype of TOMORROW. Follow his blog, or e-mail him at cloud(at)

Comments (48) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
A lfredo Amass 10/02/03 10:59:12 PM EDT

hi, just a word or in my case possibly a question. I enjoyed the tug at the latest lazy vibe in design pattern grief. Well I say grief mainly because the nuber of times I've heard a programmer/compu_geek use some lingo that set's about me rushing around ttrying to find out how the god damn dat in the structure even resemnles anything of a pattern becomes rather frustrating. I guess a singleton class of which I'm not particularly familiar is one of those ideas that I might eventually stumble across in my venture to reduce costs in developing new software, somewhat of an oxymoron when you say development and pattern together but thanks for shedding some light in the ever decreasing circles of haze that appear around my desk as I hastily throw code tigether with some idea in mind that only ever comews together in full, as experience tells me when the need really exists, and that is usually at about three in the morning when the sleep is about the only pattern that I'd really get into!

A lfredo Amass 10/02/03 10:50:56 PM EDT
Santosh Benjamin 02/28/03 11:59:00 AM EST

Look ,everyone has to communicate in some way and anything to help communicate is always good. DB designers talk in ERModelling terms, OO programmers talk in OO terms, software architects talk in design pattern terms. It may be difficult for the uninitiated, but it is NOT MEANT FOR THE UNINITIATED...i would just tell the author of the article to learn about patterns so he doesnt get scared when people talk about them .. Id rather mention the name of a pattern to a fellow sofware designer and have him/her understand it than have to write a hundred pages explaining how my solution works ..

And ALEXX, please watch the WS space closely. the current toolkits do give it a very RPC like appearance with the creation of proxies and stubs and all that but really its all about messaging and the forthcoming specs and implementations from GXA and ebXML will prove that it isnt only RPC ..Even in the MS stack there is a clear distinction as to when one uses .NET remoting (which would be the RPC equivalent) vs WS messaging ....


Dan Clamage 01/29/03 02:01:00 PM EST

Pattern .EQU. Idiom
A short-hand way of expressing a standard solution to a common or often-seen problem. It can be applied to algorithms, data structures, or a fusion of both.
Most annoying abuse of English in technology: using "architect" as a verb. It's a noun.
Five or six years ago, one of the most commonly abused (especially by but not limited to managers) bit of jargon was "Paradigm". I overheard one manager bragging to another in the hall at Lucent Technologies: "With a team of four programmers, in just six months I reengineered a new software paradigm. Now everybody is using it". I always wondered why some people memorized buzzwords. To hide the fact they have no depth of knowledge.
"Sociology" invented its own jargon so it could look and talk as if it were a real science (which it's not). If you didn't know the jargon, you were standing on the outside looking in, confused as hell. The Sociologists, meanwhile, hoped nobody would notice the trick.
Marxism attempts the same thing with "Dialectical Materialism". After reading the first page, I realized it was a pile of crap. Like Kuhn's theory of "Scientific Revolution". The material is so opaque, rather than admitting they didn't know what the hell he was saying, critics hailed it as a work of genius. The only "genius" was replacing real Communication with BS and getting away with it.
If you can communicate an idea or problem space efficiently using a Design Pattern (or any sort of pettern), which everyone around agrees to accept and understands to have to same meaning, then by all means use it. Just as long as you're not trying to impress anyone or baffle 'em with BS.
Another example of Doublespeak: "Assumptions identify things that we are considering and not taking into consideration."
- From a Year 2000 Contingency Planning document
Because the author talks double-speak as well as writes it, we dubbed this sort of gobbledygook "Parkese" in his honor (his last name is Park). This was the same nut who wanted to build an "empty" Data Warehouse as a "proof of concept" (no actual schema designed; just a DW "engine"). I told him his "vision" was BS. He said "Let's 'agree to disagree'". I said "No, you're wrong!!!"

Gary Ruble 01/27/03 07:19:00 PM EST

For those of us who've been at this for 'a while', the latest rants about the use / misuse of "patterns" is just same stuff we said and heard about "paradigms", way back when....

Mike Thomas 01/24/03 10:49:00 AM EST

To me the article is a classicly insecure, ignorant, anti-intellectual, diatribe: "Everything I need to know I learned in my data structures class. I will compensate for my ignorance and insecurity by mocking ideas that I don't understand so that what I do know gains importance." Or, "I've already thought of all these things and everyone else is stupid to think they're worth naming and cataloging. Aren't I smart?"

To me, this behavior is symptomatic of one or more of the following: insecurity, intellectual laziness, and career laziness.

On the other hand, as others have said, there are a lot of folks that throw DP and other terminology as if these things are the ends, when they are actually the means, to getting things done. Worse, they do so even when they don't really understand what they're talking about. This behavior also indicates insecurity. The appeal to authority that design pattern terminology represents gives the insecure developer "backing". This is probably worse than the anti-intellectual stance, since it reduces the power of a concept such as design patterns.

I must say that those I've worked with who are truly conversant in design patterns have been the better developers; not because they use design patterns specifically, but because they have intellectual curiosity. They feel that there's always room for improvement. They feel they can benefit from the work of others. They read books on practice as often, or more often than books on syntax. They've taken the time to understand what a concept like design patterns represents and offers, both good and bad. They may have used the techniques contained in the patterns before, but are now happy to have a common terminology with which to communicate the approaches.

DK 01/24/03 04:52:00 AM EST

That article is a waste of space - no informative content & simply designed to be controversialprovoke a response.

01/08/03 03:55:00 AM EST

Agreed that there is are few of who like to fling the word. Thing like the SingleTon pattern is not a DataStructure by any standard . And patterns are algorithms + dataStructures. not Just data stuctures . Im sure everbody will agree.

Maher Dahdour 01/07/03 12:27:00 PM EST

Design pattern is derived after the design strategy, and we should consider them as guidelines or proverbs in designing and constructing software objects and their interfaces. Design patterns are not data structures by any means, and I was surprised to read the part where you called the design pattern a data structure in the old days.

I agree with you that many software engineers use terms they might never used or understood, but that doesn't mean to underestimate the intellectual efforts of developing and applying design patterns. They are useful to the industry of software engineering if we understand them and apply them. We should use them based on our needs that derive our design strategy.

John Doe 12/09/02 05:00:00 PM EST

Design pattern buzzwords are useful, they go right up along there with the management buzzwords... get a manager to use a buzzword even better. This is what a gort is gentlemen.. check out it out at

Mr #T 11/16/02 08:05:00 AM EST

What an idiot you've become Alan ? Drinking too much scottish whisky or what ?!

dave howard 11/11/02 11:17:00 AM EST

Alan, you are getting old. This is not an ad-hominem attack. One distinct characteristic of many older engineers is that they sneer at the 'new' stuff, in exactly the mode of your editorial. This gets them in trouble when the world moves on and they hang on to what they know and refuse to learn. There are still a few C programmers sneering at Java.

Patterns solve a long term problem (maybe one of the most crucial problems) in software engineering, that of reinventing the wheel. Nothing before them solved this problem so well.

Kenneth McCafferty 11/08/02 08:31:00 PM EST

Understanding design patterns can help one write better more maintainable code.
One example is the event handling mechanism in Java. Originally the "Chain of Responsibility" pattern was used, and it was very clunky.The designers of Java decided to switch it to a "Publish/Subscribe" pattern and Java is much the better for it.If the "Java Revolution" is going to succeed, we need intelligent leaders who know how to write helpful, insightfull articles. Not, crap like this.

Larry Kim 11/05/02 03:57:00 PM EST

I really feel that Java developers are bigger pattern snobs then the microsoft or c++ developer crowd. I wonder why this is.

Tony Weddle 11/05/02 01:26:00 PM EST

Many replies have suggested Design Patterns are useful for communications. However, there is a danger here. I'm sure that there are many interpretations of patterns (some right, some wrong). If you assume that someone mentioning a design pattern is using the same definition as you then you might be in for a rude awakening. I remember this occurring a few years ago when someone arguing for his design as being the Facade pattern, was actually arguing for a completely different design, certainly very different from Facade. Another had supposedly implemented the Singleton pattern but hadn't followed the pattern, so there were a couple of surprises when looking at the code. So maybe it's better to communicate what you've actually done or are actually proposing to avoid confusion.

Robert White 11/05/02 01:22:00 PM EST

Was Alan criticizing Patterns? No, he was criticizing the notion that only by using the common terms, the officially sanctioned GoF names can one accomplish one's design goals. He's right that there are snobs out there who can list and describe the patterns, but they cannot necessarily design as well as the guy who just knows how to do it, but maybe can't explain how he knows it.

Of course, we'd prefer if every good designer were adept at explaining his design. In fact, we demand at least some ability to communicate a design to fellow team members. But must one use the politically correct terms?

Better to know when to use the Singleton pattern or the Visitor pattern or the Mother-in-law pattern (I just made that one up to see if you're still reading) than to know all the names by heart and apply them incorrectly.

Knowing Patterns is akin to knowing how to use a paintbrush -- neither skill makes you an artist.

Eric Garner 11/05/02 12:56:00 PM EST

IMHO, I ask you: Who really cares what you call it? Design Patterns, Data Structures, Thingamajigs, ...the point is we all must communicate with with one another regardless. And things, like, where you live, your project team's dynamics, their personalities, background, skills, work experience, education, etc., truly determine how you go about communicating and not some set of "buzzwords" or trendy concepts. And as for calling anyone or anything a "snob", let me tell you that snobs exists regardless of technology, or race color or creed for that matter. A snob is a snob no matter what he or she knows or pretends to know.....And, to quote a well-know white rapper..."that's my ten cents 'cuz my two cents is free."

Geezer programmer 11/05/02 12:50:00 PM EST

In my day, you young whippersnapper, we had real design patterns - you plugged the jacks into the punch board holes and created programs that not only ran fast but looked good. But then (hack, cough, wheeze) so called "experts" started coding by punching holes in card stock and made us feel old fashioned. Gul darned new fangled ways of coding - work of the devil, I say!

Ernie 11/05/02 12:33:00 PM EST

I see the point being made in the article but the real issue is those who do not posses experience climbing on something new to try to get a "step up". Been there, done that. For me it was hopping on the Java bandwagon at day one and it did have its advantages as a career move. As for patterns specifically, they are a tool, nothing more and nothing less. I was using them well before I knew what a pattern was. I view design patterns as an extension of what UML brings to the table. A common language that allows developers to communicate an application design clearly and concisely. Let's face it, when you do a design communicating the what and the why of the end result is often times more difficult than the design itself and patterns combined with UML do make that easier. I know if I come into an existing project I would rather have a few UML diagrams and a quickie on what patterns are used where than 100 pages of typed design documentation. It aids a developer in getting up to speed and uses a common language. At the same time some patterns are overused in discussion to the point of becoming meaningless. How many times have you been told "we're using the MVC pattern for this web application!"? When

Alexx (yes, a CHICK) 11/05/02 12:20:00 PM EST

What news! Design patterns are a repackaging of proven concepts. Guess what? So are web services! YARPC (yet another RPC, for those unfamiliar with GNUese).

Alan Williamson - a repackaging of Jerry Springer for the Java world. Incendiary, yes. Informative? Well, I can surf for my own "new cool java" links too.

And Rob's right - design patterns are NOT data structures. Duh, even this blonde knows that.

Rob 11/05/02 12:00:00 PM EST

Have you noticed lately how some magazine columnists make inflammatory statements that are sure to be taken as an insult just to see if there's an audience out there. Mr. Williamson, why didn't you make your points without being so insulting? Isn't this just the kind of snobbery you are railing against?

"In my day they were called data structures." Wow. Did you have to walk five miles to school every day... in the snow... uphill both ways? "Data structure" is a buzzword. If your against buzzwords, why are you using them? Perhaps it is because, in the proper context, they convey meaning.

If you think data structures are the same as design patterns then you clearly haven't got a clue what design patterns are.

Have you heard of the Model-View-Controller software architecture paradigm? This is a design pattern that was developed in SmallTalk-80. I just don't see how you could capture, document and explain this paradigm using just data structures. I'm sure any implementation of this paradigm would include data structures and behaviors.

I am guessing that you were trying to be entertaining while making your point. Instead it came across as insulting and ignorant. Live and learn. I hope you do better next time.

Brian Sam-Bodden 11/05/02 10:27:00 AM EST

I think you are mixing two issues into one murky convoluted rant. There are three effects of the "patterns" revolution.

"The Good"
Patterns are one the best things to happen to our industry. We are slowly moving towards a unified terminology. Now, architects can convey vision and ideas to software builders using well known micro-architectures (yes, patterns). Most other engineering fields that are a tad more mature than ours have come to this conclusion long ago. It is easy for a construction architect to tell an electrician to do a three-way switch that to babble for 10 minutes describing what something outside of his domain (is the electricians domain).

"The Bad"
Like with algorithms, data structures, components and other lingo-building revolutions there is still not enough understanding on how to apply this wonderful patterns. So, a lot of people are working with Patterns in a vacuum. Sometimes thinking that picking a couple of patterns per tier of functionality means that they're done architecting and designing the system. Just like with components, (remember the days when some people refer to everything and anything as "beans") patterns are just in their infancy when it comes to adoption, usage and understanding.

"The Ugly"
Of course, now you have a sleuth of people that read one or two articles and randomly throw pattern names into a conversation to feel better about themselves. These people are just devaluating the power of patterns, but as with any other good thing it is just part of the evolution of our trade. My approach to these fellows is to say: "Hey, I really don't understand the inner working and motivations for that pattern, do you care to elaborate?". Either they shut up or they will go a really learned what the hell the pattern really is for and how it works and come back and redeem themselves. All you architects out there, try that for a change!.

spic 11/05/02 10:19:00 AM EST

No wonder JDJ hasn't been getting as many good articles as in the past.
With editors like this who don't even understand the true benefits of patterns...well no wonder the good articles slip thru.
If you are so experienced, by now you should be able to see under the hood of all those patterns and judge if there is something worthwhile.

Juan Valdez's Wife 11/05/02 10:18:00 AM EST

A pattern isn't nearly as simple as a hammer.. and perhaps may not be as efficient either. There are drawbacks to patterns as well -- complexity. Yes, they do make your code more extensible and easier to maintain but it doesn't come with a price. So you don't always have to use diamond based hammers, you could always use iron ones as well if you are willing to make the trade-off.

Pawan Kumar 11/05/02 10:16:00 AM EST

Yes, there are snobs trying to show off and the insecure ones throwing the buzzwords at you. But patterns are more than data structures. I would say, they are a combination of data structures and algorithms targeted at solving commonly occurring problems - so they lie in a layer above data structures and algorithms, if you will. (I have studied hard core computer science too)

Singleton is a bad example because it is such a simple pattern that you could liken it to just a data structure.

I have often enjoyed reading your editorials but this one comes across as very disappointing. Almost seems like you are trying cover up ignorance (lack of appreciation?) of patterns by putting others down.

Juan Valdez 11/05/02 09:28:00 AM EST

Patterns are simply a tool. Nothing more; nothing less, that allow developers to define and communicate and code problems.

If a developer doesn't have Pattern in their tool belt, it's like a carpenter attempting to drive a nail without a hammer. It can be done, but nowhere as effectively.

Vince Marco 11/05/02 09:23:00 AM EST

So the real question is "does your article help to stoke or cut through the hype"? Suggesting that design patterns are merely the same old data structures is perhaps like saying that C++ really is just C with a few enhancements. Some people do code that way. Data structures allow grouping of information and our problem with data structures 15 years ago was that we didn't provide a consisent way to express the behavior of a technique.

I think your message has been convoluted. It shouldn't be that design patterns are just rehashed data should be that rather than be intimidated by design patterns developers new to them should embrace them because they are similar to data structures they've done in the past. We need design patterns. Using design patterns doesn't make one a snob...although snobs do use technology just like the rest of us.

I wish your article had touched our current mismanagement of patterns. We've got so many groups managing patterns that patterns risk losing the quick communication of a design technique that was intended. Value Objects vs. Value Types is an example. Who teaches the finer points of naming and project organization anymore. How about "what is accidental complexity and how to avoid it". Now those would be worthwhile articles or rants that open up some new ground!!


Andrew Wolfe 11/05/02 09:00:00 AM EST

Thanks, Alan. It's time someone pointed out this Emperor's nudity. "Design patterns" are little more than a way of calling a half-baked draft some sort of elegant solution and intimidating critics by some claim to "standardization."

Their very imprecision, which should be the tipoff to their vacuousness, is turned by Patterns proponents into some sort of benefit. After all, you can't criticize a spec that doesn't actually specify something.

The problem is that "patterns" are not even really data structures. If they were data structures, then they would have more weight, and they would be easily assessed and utilized.

Unfortunately, they aren't algorithms, either. If they were algorithms, they would have a fixed set of clear implementations.

Finally, they aren't even completely naming conventions. If they were naming conventions, they would facilitate communication and understanding of code. But unfortunately the Patterns people blink before making even that commitment.

What's worst of all about patterns is that the power of Java and other languages should render them unnecessary. I mean, really! I worked in FORTRAN and other unstructured languages. For them, "Design Patterns" would have some real benefit -- because the reuse capabilities are so poor.

But with Design Patterns, you can reduce your Java coding to the unreusability of FORTRAN -- not because the language won't support reuse, but because Patterns are an intentional avoidance of reuse. But I suppose that makes people hire more Java coders!

Show me a pattern with anything more to implement than a simple naming convention, and I'll code a Java class that you can use without reading 300 pages of mumbo-jumbo.

Johan Nagels 11/05/02 08:58:00 AM EST

Does anybody know a _good_ Java developers newsletter (except for Sun's newsletters, which are excellent but not independent). 'cause I'm getting fed up with JDJ's rubbish.


goutham 11/05/02 08:42:00 AM EST

Take a look at, and the Gui2Go platform.

William Davis 11/05/02 08:27:00 AM EST

Well Alan, your clueless rantings have caused me to reach the saturation point on this one.

So patterns are just data structures? That would make the Model-View-Controller pattern just 3 data structures. So, Alan, why not simplify the pattern to just use 2 data structures, or even just one? Could it be that the behavior of the structures actually matters?

Classes are more likely candidates for being just data structures. At least when you ignore the behavior of a class, you do not have the question of why another class with no behavior is somehow related.

Alan, your day has obviously not included anything remotely close to a proper education or even useful self study in the software engineering field. You need to read the Programming For Dummies book that I just saw advertised. Then maybe your next column would have some credibility.

Paul Folbrecht 11/04/02 11:17:00 PM EST

So, do you feel the same way about "OO snobs" or perhaps "GUI editor" snobs (you know, those programmers who no longer use vi)?

C'mon, there are snobs regarding any area of knowledge but design patterns have actually been with us quite a while now and have certainly added something of value to the industry, for real-world developers, not just head-in-the-clouds theorists.

If you have actually never read the book that started the movement, Design Patterns (Gamma, et al, 1995)- and if you haven't, I'm surprised- give it a once-over and see if you don't agree that it's good stuff. As others have pointed out, the biggest value in them in just the common lingua franca- the ability to express something moderately to seriously complex in a simple way that many people understand. That, and they're a great tool for organizing your own thoughts, I think. Isn't commonality a good thing in this industry? Even if you're already familiar with a concept, having developers who implement that concept in the same sort of way leads to shorter API learning curves, easier maintenance, etc.

So, those things, and one more- a couple of the more complex patterns in DP I probably never would have come up with myself, at least not a solution as elegant as what's presented.

Jim Thomas 11/04/02 09:42:00 PM EST

You could've written this several years ago.

Dave Higginbotham 11/04/02 08:29:00 PM EST

I've employed the Reply Pattern in responding to this drivel. The author is misusing the grumble pattern in an attempt to expose use of what might be called "the buzzword pattern". I'll let you in on a secret - there IS no such pattern! In my day, we called this "bull*&#@-ing". I see a trend here; perhaps even a pattern....

Chris Colman 11/04/02 08:04:00 PM EST

I wholeheartedly agree!!! It frustrates me as much as max(reallyFrustrated, MAXFRUSTRATION_TOLERABLE) to find people new to OO using names of "patterns" as a way to look down on others in there conversations. (Like others who would look down on me because I just used 'there' instead of 'their' in the last sentence).
I have no problem assigning industry accepted names to common patterns and using them in design discussions but to use this as a tool to raise one's self above another more experienced developer - no way.

Of course people who resort to such low life "social patterns" are usually socially inept in the first place and need every straw they can clutch but that's a whole 'nuther topic!
They try to infer that I don't have a clue even though I have been a die hard OO'er for 12 years and have developed from first principles and used time and time again many of the patterns they refer to. I just gave them different (and sometimes interesting) names or sometimes I didn't even get around to naming them at all.

For example: the template pattern - have you read about that one? I couldn't believe what I was reading - someone actually put a name to and used a couple of pages to describe one of the most fundamental uses of OO upon which nearly everything else is built - I thought it already had a name: polymorphism. Hello!!! - every superclass has an interface that forms a template which subclasses can conform to or implement in their own way.

I have been using a pattern I called subject/observer for seven years now - some &*$%^% tried to make me look like an idiot by explaining that I should be using his great new Observer pattern instead of the subject/observer pattern I was using. I humbly decided it was a good idea to move up to the new technology: until I realized the class design of both were exactly the same!

Quite often I have a need to tranverse a complex object model and perform certain operations on various objects in the model. Instead of writing the complex traversal code each time I needed to perform a certain operation on the objects I developed a mechanism whereby the traversal code was written once and then I sent an object that I called a "Beaver" through the traversal mechanism.
The Beaver "visited" each object in the model and performed whatever function that particular Beaver was developed to perform (Beaver was an abstract base class, many different concrete Beavers derived from the base to perform specific tasks). I called it Beaver because the object traversal path reminded me of a complex set of tunnels in a Beaver's home on the river. Ok so I invented the "Visitor" pattern but gave it the wrong name - sorry guys! Visitor pattern is such a boring name but because it is the "well known" standard I've had to drop the Beaver name!

Long live the Beaver!!!
Maybe someone should start a counter revolutionary movement with veteran OO'ers who call patterns by their interesting names that they were first assigned when they conceived pre-patterns era! Anyone got any other interestingly named patterns?

Anil 11/04/02 05:13:00 PM EST

I shall promptly unsubscribe from JDJ's spam and instead get the real stuff from JavaWorld, and

This is spam-by-other-means. Dont waste our time.

Paul Frey 11/01/02 09:32:00 AM EST

Ok, I agree many developers fling around buzz words and catch phrases just for ego sake. I also used to have the same view of design patterns that you discuss in this article. However, I've grown up since then. I now see some of the benefits to design patterns since I've been doing quite a bit of analysis work lately. The main benefit is communicating complex ideas in the least amount of time. The same reason held true for data structure nomenclature in the past (yes, I was here before design patterns as well). Although, I would argue that design patterns are more sophisticated and communicate more information than data structures.
Using design pattern terminology assists me in reducing the time it takes to describe complex solutions to problems in the shortest time. I worked with a team of developers that I had to bridge the gap between older terminology and design pattern terminology. It took longer to conduct the meeting. Also, new members, who already understood design patterns, didn't miss a beat.
Design patterns are a good thing ;)

fjfish 12/03/02 04:52:00 AM EST

What a charming idea, reusing code. In fact, in my experience what is reused is the design, which is what patterns are about.
I do agree with the article though, after being on the receiving end of several design documents full of URLs pointing to Sun's website to back them up. Frankly the patterns were being used as a substitute for proper dialogue. ("We must be right/better than you/blah because Sun say it" - get lost and have a brain implant, understand the business need first and I'll get back to you).
When used properly as a communication aid they are great, but otherwise hold back on the religion.

John 11/27/02 04:22:00 PM EST

First, a clarification about patterns: they are language independent. Originally developed in the SmallTalk world, patterns are applicable to most any object-oriented development language.

Much of the benefit of object oriented software development is based upon the reuse of existing code. Patterns define reusable collections of classes that are known to solve a common or frequently occuring software engineering problem.
In many ways, a pattern can define a "best practice" design for solving a particular problem.

So, what're the benefit of patterns? Well, why reinvent the wheel if you know that someone else has solved a similar problem in a particular manner? Why not just implement that pattern and save yourself the headache of designing your own solution? This explains why many developers enthusiastically embrace patterns.

I can't say that I've ever encountered a "pattern snob", except for that breed of person who throws around any buzzword that they think will make them appear more proficient than they really are. This isn't a characteristic of patterns so much as of the people who feel the need to appear smarter than others, like those people that want to publish an article in a magazine. One could say the same thing about web services (which frankly I don't understand the whoopla over) or any other tool or technique that people want to learn more about.

The abuse heaped upon Mr. Williamson is IMO well deserved due to what appears to be his ignorance of patterns and his comments slamming them. His criticism would be better directed at those who seek to impress through use of jargon, but that would be biting the hand that feeds, wouldn't it?

Finally, java developers are no more critical than any other practitioners. I think the reaction was more like "if you don't know what you're talking about, keep quiet, even if you edit a magazine."

Vince O'Sullivan 11/27/02 08:02:00 AM EST

I read the article with interest. Certainly it's about time that someone questioned the concept of patterns and we had a debate about it.

Sadly half the replies seem to be nothing more than personal abuse of someone who questions cherished beliefs. Unfortunately, this sort of response is very much a feature of the Java development community. I can't think of any other computing language where the community behaves in such a fashion to the same extent.

My experience of patterns is that they only exist if you know that they're there. I work in a development environment where a large percentage of the developers have no knowledge of their existence. It's no good me saying "I've used the abstract factory pattern here..." unless I'm prepared to get into a long discussion about patterns, what they are and what they do. Simpler, and more practical just to say "You create an instance of class X by calling method Y with parameter Z." and documenting the fact. Around here dropping "patterns" would only get you blank looks. Since 90% of our work is dealing with legasy code then I've found very few instances where we can practically apply patterns anyway.


John 11/26/02 01:24:00 PM EST

Wow, Alan's ignorance of design patterns coupled with his vociferous demonstration of that ignorance has diminished his credibility in my book. Now, I feel compelled to view everything he says with skepticism.

Aidan 11/26/02 12:05:00 PM EST

and counted to ten before you wrote that article.

Your apparent frustration at dealin with a design pattern snob seems to have been misdirected at the whole idea of having design patterns. You seem to have implied that anyone speaking in terms of patterns is a snob.

They enable a common set of good design structures and interactions to be classified and organized for communication between engineers, and that's obviously a good thing.

parvez 11/26/02 02:03:00 AM EST

With due respect to your knowledge I want to comment pattern tell u How to Solve a problem in a given scenario chiding and remarks like made on singleton pattern only shows that the author does not a thing about pattern

Dave Glasser 11/07/02 04:00:00 PM EST

If someday, Alan Williamson comes to understand what design patterns are and what purpose they serve, he'll likely cringe with embarassment that he once wrote (and someone published) the line, "In my day they were called data structures." Uh, no, Alan. Design patterns often employ data structures, but for you to declare them the same thing as data structures reveals the depth of your cluelessness.

On the other hand, AW is right that "pattern" has become the buzzword du jour, and a lot of developers, I suspect, like to throw around pattern names to impress others. What's worse, some developers feel duty bound to use every possible design pattern they can wherever they can, and the result is not pretty.

Steve 11/07/02 05:42:00 AM EST

It is apparent you've struck a nerve with some of your readers. I can't help but chuckle to myself whenever I see someone use their "education" as validity for their chosen profession. I find it just as amusing that the "programers" with a formal education seem to be the ones that cling to these buzzwords more often. It must be awful to not feel valid without being able to use some special terminology to woo people when explaining to them what you do for a living. If there is one thing about being a developer and participating in the developer community that I hate is all of the f*(&!#$ buzzwords and coined phrases!! Cheeeeeeeeeeeeeezy!!!

Michael 11/06/02 04:38:00 PM EST

It's true that there are many people out there more interested in showing off how much knowledge they possess and how clever they can be to those around them than actually contributing to a team's effort. Many of those people may throw 'buzz words' around, some of which may be pattern names, but how does that diminish the value of Design Patterns?

Design Patterns do much to help in the development process, least of which is communicating the detail of design structures both conceptually and specifically. They enable a developer/designer to more easily discover classes and place responsibilities where they most correctly belong when applied to issues often repeated in the real world. Is that so very wrong? How silly and show-offish of me to think so.

Hackers may disagree with the use of Patterns - exactly why again do you?

CS 11/06/02 03:42:00 AM EST

They are a good thing to have...most developers will agree that if you write interfaces and base classes around a particular pattern design then you can reuse the same pattern, for the same type of task, over and over again!

What does frighten me is when developers *always* turn to the pattern book! Could they come up with something better?

What I am trying to say is

* Dont be afraid to innovate *

Without innovation we wouldn't have Linux, J2EE, Apache...I rest my case.

Yousef Syed 11/06/02 03:15:00 AM EST

Putting down Design Patterns just cos some teeny-bopper Acronym Junkies are showing off, is just Sad!
(GROW-UP Alan!)
You can make the same complaint about ppl that use every J2EE based acronym (EJB, JSP etc...). Or, complain about OO languages because you may have seen some diabolically bad code!

That does not take anything away from the importance of the technology or knowledge. Design Patterns are great. They are not just glorified Data Structures! They aren't Data oriented, they are OBJECT-ORIENTED (Behavior based).
Basically, a design pattern is a reuseable design to solve a recurring problem.
It is not based in code. The design can be reused across various OO languages.

Getting bogged down in the NAMES isn't the point. The point is that when you come across a recurring problem, you have that same design solution to hand ready to reuse. Knowing it's name just helps. If the other members of your team also know the names and nature of the design patterns and various ways to implement them; that makes for good Software Development.