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 ...
|
|||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
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 |
|
|||
|
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 > |
![]() |
| Thread Tools | |
|
|