
- Forum
- Testing
- Software Patterns
- Bridge and Strategy
Bridge and Strategy
This is a discussion on Bridge and Strategy within the Software Patterns forums, part of the Testing category; HI All, Can anyone direct me to some article or other publications that can clearly differentiate between Bridge and Strategy ...
-
12-21-2004, 05:36 AM #1Shashank Guest
Bridge and Strategy
HI All,
Can anyone direct me to some article or other publications that can
clearly differentiate between Bridge and Strategy patter.
Isn,t the instantiation of concrete classes in Bridge pattern, is
actually depends on Strategy pattern?
I need little more clarification that will make the differences obvious
in terms of their usage and structure.
thanks in advance,
Shashank
-
12-30-2004, 10:50 AM #2Bruce Trask Guest
Re: Bridge and Strategy
Hi Shashank,
Here some data on this subject from Robert C. Martin that I found
helpful. The below are quotes taken directly from his newgroup postings
to comp.object the archives of which you can find on google.
-----------------------------------------------------------------------
From Robert C. Martin:
"A strategy is simple polymorphism.
|Context|----->|Strategy|
A
|
|SpecificStrategy|
The context has some algorithm that depends on facilities provided by
the Strategy. Derivatives of the Strategy implement those facilities
differently.
A bridge is a way to manage multiple degrees of freedom, preventing
them from creating a geometric explosion of derivatives. Thus,
instead of:
|Employee|
A
|
+--------+----------+
| |
|Salaried| |Hourly|
A A
| |
+------+------+ +--------+--------+
| | | |
|SalariedUnion| | |HourlyUnion| |
| |
|SalariedNonUnion| |HourlyNonUnion|
We build:
|Employee|-------------->|UnionStatus|
A A
| |
+-------+--------+ +--------+---------+
| | | |
|Salaried| |Hourly| |Union| |NonUnion|
This is explained in much greater depth in the appropriate chapters of
"Agile Software Development, Principles, Patterns, and Practices",
Robert C. Martin, Prentice Hall, 2003. www.objectmentor.com/PPP
Bridge is a special case of Strategy. Strategy is simply the
invocation of a polymorphic function on an object. In strategy there
is only one polymorphic hierarchy.
In Bridge there are two polymorphic hierarchies. A call to the first
polymorphic hierarchy invokes a call to the second.
Moreover, the intent of the pattern is to separate implementation from
abstraction. The first polymorphic hierarchy represents an
abstraction, and the second represents an implementation.
To say this another way, Bridge is used whenever you have a hierarchy
with more than one degree of freedom."
---------------------------------------------------------------------
And so for me it is all about commonalities and variabilities and
handling degrees of freedom in your software. The Strategy Pattern is
all about handling an algorithmic variability and making it look common
to a context.
A given context class can have multiple relatively independent
strategies with no particular Bridge present.
Bridge does something similar but there are more degrees of freedom
*and* there is some important relationship between the two degrees and
that relationship is loosely summed up as "one uses the other" and is
implemented via the aggregation relationship between the two.
Hope this helps,
Bruce
"Shashank" <shashank@icmgworld.com> wrote in message
news:41C7EEA8.4543EBF3@icmgworld.com...
> HI All,
>
> Can anyone direct me to some article or other publications that can
> clearly differentiate between Bridge and Strategy patter.
>
> Isn,t the instantiation of concrete classes in Bridge pattern, is
> actually depends on Strategy pattern?
>
> I need little more clarification that will make the differences obvious
> in terms of their usage and structure.
>
> thanks in advance,
> Shashank
>
«
do you know "rational rose" news group? or can you use the rational rose?
|
CFP: 4th AOSD Workshop on Aspects, Components, and Patterns forInfrastructure Software (ACP4IS)
»

Reply With Quote





