Skip to Content.
Sympa Menu

gang-of-4-patterns - RE: [gang-of-4-patterns] Strategy Pattern vs. Bridge Pattern

gang-of-4-patterns AT lists.siebelschool.illinois.edu

Subject: Design Patterns discussion

List archive

RE: [gang-of-4-patterns] Strategy Pattern vs. Bridge Pattern


Chronological Thread 
  • From: Ray Ye <rayye AT Catena.com>
  • To: "'cfinlayson AT vls-inc.com'" <cfinlayson AT vls-inc.com>, gang-of-4-patterns AT cs.uiuc.edu
  • Subject: RE: [gang-of-4-patterns] Strategy Pattern vs. Bridge Pattern
  • Date: Thu, 6 Nov 2003 09:32:40 -0500
  • List-archive: <http://mail.cs.uiuc.edu/pipermail/gang-of-4-patterns/>
  • List-id: Design Patterns discussion <gang-of-4-patterns.cs.uiuc.edu>

Hi Chris,

The intent and implementation between these two patterns are totally
different.

What you described here is a classic example of strategy pattern. In
strategy pattern, the context is concrete and not changed, and strategy
could be changed dynamically.

In bridge pattern, you have two-dimensional requirements. The Abstraction
have multiple variants, and its implementor can also have variants.
(referent to the structure of bridge pattern).

Now think the following example,
A modem class, it has two different types, e.g., DialModem and
DedicatedModem (different types means different behaviors for modem
interface), and they also can be manufactured by different manufacturers,
e.g., Hayes, USR, etc. (different manufacturers means different
implementations) if the modem interface is something as follows,
public interface Modem {
public void dial();
public void hangup();
public void send(char);
public char read();
}

How can you solve the problem nicely when there will be new manufacturers or
new types of modems involved using strategy pattern? It really does not fit
in here.

Hope this helps,

Cheers,

Ray


-----Original Message-----
From: Chris Finlayson
[mailto:cfinlayson AT vls-inc.com]
Sent: Wednesday, November 05, 2003 5:26 PM
To:
gang-of-4-patterns AT cs.uiuc.edu
Subject: [gang-of-4-patterns] Strategy Pattern vs. Bridge Pattern


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





Archive powered by MHonArc 2.6.16.

Top of Page