Design Patterns discussion

["Paul Adolph" <padolph AT lsil.com>]

I agree. But I still think using the pattern name can communicate intent
very well on its own in many cases.

For the strategy/(degenerate)bridge example at hand, if my intent is that
the implementation will vary, then I will call my solution a bridge. If some
sort of algorithm is varying, I will call it a strategy. In both cases the
code structure will look very similar, but the participant names will be
different. Right away, without any other info, someone familiar with GoF
will be on his/her way of knowing what I am doing.

> -----Original Message-----
> From: ziane 
> [mailto:mikal.ziane AT lip6.fr]
> Sent: Thursday, November 06, 2003 3:21 PM
> To: 'Paul Adolph'; 
> gang-of-4-patterns AT cs.uiuc.edu
> Subject: RE : [gang-of-4-patterns] Strategy Pattern vs. Bridge Pattern
>
>
> Indeed the Problem part of a pattern is essential.
> But the problem that a pattern addresses is often difficult to identify
> clearly. It is often mixed up with the pattern's solution.
> For instance the Intent section seems a bit ill-named since it does
> include the solution.
> There are also sometimes different problems adressed by the same
> pattern.
>
> Hence I would not trust too much what is communicated through a
> pattern's name in documentation.
> Hence I think that designers should make their quality objectives and
> principles explicit and then document which mechanisms (e.g. refactoring
> transformations) where used to enforce them.
> Patterns are great but not enough.
>