Design Patterns discussion

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

In general, there are a lot of commonalities in many of the GoF patterns.
This should not be surprising, since most patterns rely on the principles of
polymorphism, delegation, and generally separation of concerns.

Bridge, Strategy, and State all have very similar structures. Looking just
at the structure diagrams in GoF it is hard to tell them apart. This is one
of the reasons why some experts consider the structure diagrams harmful. In
any event, it is their intent and application that are widely different,
which in GoF are discussed in the Motivation, Consequences, and
Implementation sections. So the real distinction is how you choose to think
about the problem, what kind of flexibilities you need, and most importantly
what you want to communicate to those reading your code.

In Martin Fowler's "Refactoring" book, he comments on the similarity of
State and Strategy in his initial refactoring example (p. 39):

"Is this a state or a strategy? ... At this stage the choice of pattern (and
name) reflects how you want to think about the structure. At the moment I'm
thinking about this as a state... If I later decide a strategy communicates
my intention better, I will refactor to do this by changing the names."

I think Bridge would also fall into this question as well.

This underscores the value of patterns as a design communication tool. Not
only do you get ideas on how to solve recurring problems in software design,
you get a vocabulary with which you can describe how you are thinking about
the problem and what about it you deem important.

> -----Original Message-----
> From: 
> gang-of-4-patterns-admin AT cs.uiuc.edu
> [mailto:gang-of-4-patterns-admin AT cs.uiuc.edu]On
>  Behalf Of Wayne Cannon
> Sent: Thursday, November 06, 2003 8:13 AM
> To: 
> cfinlayson AT vls-inc.com
> Cc: 
> gang-of-4-patterns AT cs.uiuc.edu
> Subject: Re: [gang-of-4-patterns] Strategy Pattern vs. Bridge Pattern
>
>
> Chris,
>
> I think you are making a very good point, but possibly not in quite the
> way you are thinking.
>
> The Bridge pattern is one possible approach to implementing the Strategy
> pattern.  The Bridge pattern has many other applications, and the
> Strategy pattern can be implemented many other approaches.
>
> Some purposes of the Bridge pattern are to support multiple alternative
> implementations of the same interface that (1) can be selected at run
> time, (2) can change during execution, (3) that may be unknown at
> compile time, and/or (4) that you wish to keep as a clean "arm's length"
> abstraction from other code.  Any of these could potentially be
> applicable to Strategy implementations (Concrete Strategies).  The GoF
> book elaborates on these (though it doesn't break down the list quite
> the same way I did).
>
> An example of one application of the Bridge pattern that I use is to
> download "device driver" and "GUI" software from the device itself
> (e.g., from a printer, for an example using a common device type) at
> run-time.  The application contains the device driver "abstraction" that
> for the interface, and that abstraction is the only publicly-known set
> of objects.  A factory (private to the abstraction) downloads the
> "concrete implementor" from the selected device (which can be cached, as
> appropriate).  This assures that the appropriate device driver (concrete
> implementor) is always used for the specific device type and version.
> If a software upgrade of the device is performed, the current concrete
> implementor can detect the change and allow the abstraction and its
> factory to delete the current concrete implementor and download the new,
> upgraded concrete implementor of the device driver for the upgraded
> device without disturbing or even notifying the rest of the application
> -- all at run-time, automatically, without user intervention or stopping
> and re-starting the application.  The application does not know how many
> device types or versions there are, and does not know about new device
> types developed after the application has already been shipped to and
> installed at a customer site.  Via the abstraction, the application
> simply downloads the software from the device, performs a compatibility
> test, and uses the device-supplied concrete implementor of the device
> driver.  The device-specific "GUI" component is handled the same way,
> allowing GUI elements specific to the device type and version -- e.g.,
> selections related to color printing for color printers, related to
> duplex printing for duplex-capabile printers, related to calibration for
> newer printers with that added capability, etc., to follow the printer
> analogy.  As with the device driver, this allows software upgrades of
> the device to be automatically reflected in new GUI elements for new
> device features.
>
> Similar approaches could be used to allow various context-specific
> Strategy implementations (Concrete Strategies) to be selected and
> installed, "plug in" fashion, at run-time, potentially from sources that
> were unknown or unavailable at compile time, such as those developed
> after the application has shipped to customers.  Other implementations
> of Strategy could include switch statements, Concrete Strategy passed to
> the constructor (as is done for the Java SortedCollection class), etc.
>
> Regards,
> Wayne
>
>
> Chris Finlayson wrote:
>
> >Hello everyone,
> >
> >It seems to me that the Strategy Pattern and Bridge Pattern are
> equivalent
> >both in intent and implementation, therefore I must have a
> >misconception....I was hoping if someone could help clarify my
> >understanding.
> >
> >Let's focus on the application of a strategy pattern as applied
> to sorting.
> >
> >Assume I have a few sorting algorithms that do the same thing...take in
> >numbers, sort, then spit out numbers.  Therefore, I could have:
> >
> >1. ISortStrategy - the interface to the concrete strategies
> >2. QuickSortStrategy - A concrete sort strategy that implements
> >ISortStrategy
> >3. MergeSortStrategy - Another concrete sort strategy that implements
> >ISortStrategy
> >etc....
> >
> >Now, in the context of the program that's calling the concrete
> strategies,
> >it instantiaties an ISortStrategy (maybe via a factory with the proper
> >argument as to whether to use a QuickSort, MergeSort, etc.).
> >
> >Now, I see this as identifical to the Bridge pattern....where the
> >ISortStrategy is the abstraction and the concrete sort strategies are the
> >implementations.  What am I missing?
> >
> >Thanks!
> >
> >--Chris.
> >
> >
> >_______________________________________________
> >gang-of-4-patterns mailing list
> >gang-of-4-patterns AT cs.uiuc.edu
> >http://mail.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns
> >
> >
> >
> >
>
>
> _______________________________________________
> gang-of-4-patterns mailing list
> gang-of-4-patterns AT cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns