Design Patterns discussion

[Wayne Cannon <wcannon AT sonic.net>]

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
>
>
>