Jeffrey Palermo (.com)

Sponsors

The Lounge

News

Recent Posts

Syndication

Tags

View more

Archives

Advertisement

Jeffrey Palermo (.com) » Design patterns are only useful if. . . - level 200
Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Design patterns are only useful if. . . - level 200

Design patterns are only useful if the team has a shared vocabulary.  In other words, when you say the name of the design pattern, the others on the team must know what that means.  Otherwise, it's like a foreign language.

I was having lunch today with a co-worker, and we discussed the meaning of design patterns.  A singleton is only a singleton if we all agree that we are going to call it "singleton".  An "observer" pattern is only that if I can say "observer" and the other members of the team know what I'm talking about.  Design patterns are a shared vocabulary.  It's a way to speak in shortened jargon and convey meaning. 

Every field has their own jargon, and in software, we one of our categories of jargon is design patterns.  In football, you can tell a receiver to run a bootleg pattern.  Some teams have unique names for pass routes as well.  The words only have value because everyone on the team shares the vocabulary.

Consider this scenario:  A developer goes out and reads several design pattern books and then comes back and starts using the new terms in design conversations.  This has no value since the new terms have no meaning to the rest of the team.

Design patterns are useful when they can be used to convey specific meaning in design conversations.  On my team, if I say "I'm going to stub the web service call", everyone knows that I am going to make a class that will fake the behavior of the web service so that the client code can function without the SOAP call actually occurring.  A stub obviously isn't the most glamorous design pattern, but all these small pieces of jargon help when communicating on a software team.

It is very helpful for design patterns to be a shared understaning throughout the industry since we communicate about software beyond team boundaries.  I love that there are plenty of books on the topic these days, but it's a shame that more developers don't share the terminology.

Posted 04-05-2006 8:56 PM by Jeffrey Palermo
Filed under:

[Advertisement]

Comments

Sam wrote re: Design patterns are only useful if. . . - level 200
on 04-06-2006 12:12 AM
I think the shared vocabulary stuff is important, but I'd disagree overall. Several of the patterns books mention that design patterns were used before we had a common vocabulary.

Case in point: I wrote a parser recently that used Decorators to break up the task of parsing a file in a way that was non-specific to a given file. This is a pretty big departure from the "1 file, 1 parser" mentality the company generally employs. Only I and one other coworker would probably recognize it for what it is though (Decorator). I really don't think that has much bearing on it's utility however.

The idea of a common vocabulary is important then, definitely. But only in that it helps us abstract the idea of a particular construct in such a way that it's reproducable (sp?) and allows us to reapply it in different contexts to solve new (to us) problems.
Jeffrey Palermo wrote re: Design patterns are only useful if. . . - level 200
on 04-06-2006 12:24 AM
The shared vocabulary was the point of the whole post, so I'm not sure what you are disagreeing with.  

I'm not saying that the OO techniques described in published design patterns aren't useful (I think they are tremendously useful).  I'm not commenting on OO design at all.  I'm saying it's important that the words used to describe the design technique be shared among developers.

The Decorator pattern solves a particular problem, and it's valuable for that.  The name "Decorator" is valuable only when those hearing the word understand it's meaning (the software problem, and the technique used to solve it).
johnwood wrote re: Design patterns are only useful if. . . - level 200
on 04-06-2006 1:16 AM
I think this is the key to the whole post "It's a way to speak in shortened jargon and convey meaning. " - and I agree completely. While we still used these patterns before they were labeled, it would just take us longer to communicate ideas based around the patterns because we would have a handful of different ways to describe them - not just 'decorator' or 'observer'. Without a common language it's far more difficult to communicate.
Foxey wrote re: Design patterns are only useful if. . . - level 200
on 04-06-2006 3:55 AM
I think Sam was commenting on your opening statement "Design patterns are only useful if the team has a shared vocabulary" and focussing on the word "only".

Just because my colleague doesnt know what a decorator is, doesnt mean that it is not useful to me and therefore my employer. Sure I might not be able to convey my ideas in such a succinct way in a design meeting but imo thats only a small part of design patterns, its better to use them that to talk about them ;)
Jason Haley wrote Interesting Finds
on 04-06-2006 6:05 AM
Dennis wrote re: Design patterns are only useful if. . . - level 200
on 04-06-2006 7:18 AM
I think a company needs to have descriptions of patterns and common terms. In my study I wrote an article about design patterns and the usage of it(can be found in my weblog(in Dutch)). I find design patterns usefull. I agree in that all people have to know what they are talking about.
karl wrote re: Design patterns are only useful if. . . - level 200
on 04-06-2006 7:53 AM
I think that's part of the fundamental aspect of what a pattern is - otherwise it's just some code that does a trick. If a pattern isn't easily recognizable (i.e., with words), then it isn't a pattern. It can still be used and can still solve a problem, but doesn't have the global understandability that you'd otherwise have.
Tim Murphy wrote re: Design patterns are only useful if. . . - level 200
on 04-06-2006 9:18 AM
I think the key to making patterns more widely used is for those of us who have studied and practiced them to educate the teams we work with.  Also, if a team member doesn't understand a pattern name when it is used you would think they would say something like "what the #*&! are you talking about".  If they aren't asking these questions you might have other problems to deal with.
johnwood wrote re: Design patterns are only useful if. . . - level 200
on 04-06-2006 11:26 AM
A lot of people dismiss patterns because they don't see anything new in them. "Dependency injection? I've had plugins in my application for decades". But the point they're missing, which you highlight here, is that it's not the design itself that is a new invention, it's just the concise terminology - and of course a reference point to save you the time of recalling exactly how the pattern works, avoiding common pitfalls and creating some discussion in the community to make sure it really is the best solution for the problem.
Sam wrote re: Design patterns are only useful if. . . - level 200
on 04-07-2006 11:46 PM
Foxey hit it. For some reason I guess the big h2 title stood out for me. ;-)

johnwood: See, I still think it's the actual code that's valuable, and the ability of a book like PoEAA to change how many many coders get the job done. The names are helpful, but not necessarily a must for me. For example you refer to DI as if it equates to plugins, which is odd to me since my fave DI tool by far is Windsor Container.
Bjørn Reppen wrote re: Design patterns are only useful if. . . - level 200
on 04-08-2006 6:27 AM
Right on johnwood!  There's no rocket science in design patterns, it's only about terminology.

The 2 problems I have with design patterns is:

a) The above mentioned problems that can occur when one or more members of the group doesn't know what the flyweight pattern is.  (I don't know it myself, I only remember the name)

b) The other problem can occur after (some) developers have been studying design patterns and then proceed to try and find ways to (over)use them as much as possible in their code.

"Make things as simple as possible, but no simpler."
 -- Albert Einstein