Question concerning the use of patterns

[Svend Rost]

Hi,

When you use patterns, do your class diagrams actualy
look like the ones printed in, say the GoF book ?

When im making software, im often saying "I'll use Memento here to
save the objects state, and Strategy to ...", but when I compare my "class diagram" with the one found in the GoF book (if we'r talking about Memento for instance) then they normaly arn't alike..

Now, eighter im beeing stupid and my designs are bad OR im actualy
beeing smart..

Any views?

Thanks in advance

/Svend Rost

[ October 18, 2004: Message edited by: Svend Rost ]
[ October 18, 2004: Message edited by: Svend Rost ]

[Edwin Keeton]

There are many (correct) ways to implement a single pattern.

[David Hibbs]

Patterns are exactly that; patterns. They are abstract, basic solutions. Exact implementations will, by necessity, vary from the abstract "ideal" depending on what it is they need to do.

Don't spend too much time worrying about your class diagrams matching, as the diagrams are there to help you understand the concept and get a start at using it. They're not the "end-all be-all" solution by any stretch.

[Svend Rost]

Thanks for the answers.

/Svend Rost

[Eric Freeman]

Exactly what David said! Or as Erich Gamma says, "patterns are tools not rules."

Like any art, learn the fundamentals but vary them as needed in your own designs. You'll find that the implementation of patterns varies greatly across the Java API and elsewhere. Just make sure you document you pattern usage so other developers can recognize them as patterns and where they might differ from the "classic" patterns.

Shameless plug: we cover a lot of this ground in Head First Design Patterns which is at the printers as we speak!

[Stan James]

Well said.

What happens over time is you kind of have the patterns in your head and as you're coding along you say, "Hey, this problem or solution is starting to feel a little like X. Let's read up on X and see if it has any useful advice. Wow, that vibration problem never occurred to me. It looks like we might want to add a damper!"

I have a publisher with package comments like "This like GoF Listener. It uses the option blah mentioned under alternatives. The reason was ... the benefit is ..."

You may decide to refactor some class or method names to match the patterns book, just to make it easier for future generations to connect with what you were doing. I didn't do that with my publisher because it was just enough variation on the pattern that the pattern names might be misleading.

BTW: Vibration is from an old anecdote. Sorry if it made no sense up there.

[Stan James]

Ok, I have a few minutes more now for the vibration story ... supposedly true ...

Early in the days of the moon project at NASA, one engineer realized he was in way over his head. There was a long technical discussion of all kinds of issues he didn't understand. He kept his head down in the corner as long as he could but finally somebody turned to him and said "Do you have any other thoughts on this?" He froze for a second and then coolly said, "What about the vibration?" The others said "Oh, how could we have forgotten about that!" and went back to work busily solving the vibration problem. People started coming to him with vibration problems and over time he became the vibration guru.

So any time somebody presents a complex design and I have nothing else to say I ask "What about the vibration?"

[Svend Rost]

Thanks again..

@Eric Freeman :

Just out of curiosity. Do you have a source for that quote?
(as in GoF page xzy)

/Svend Rost

[Ilja Preuss]

Christopher Alexander, "A Pattern Language"
Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.