Strategy vs. Bridge Patterns RRS feed

All replies

  • Both of these so-called deisgn patterns are total nonsense.

    Every example I have ever seen which claims to be an example of the bridge pattern is nothing more than polymorphic inheritance with a bit of composition.  You define some virtual or abstract methods in some class, you create a few descendents of that class that do different things, and then you call your abstract class your bridge as if you just did something amazingly clever and design-y.  If you make this inheritance hierarchy a member of another class and provide some way of picking which descendent to instantiate at runtime, well golly, now all of the sudden you've implemented the fabled strategy pattern!  Right...

    That's the reason you're confused and that's the reason nobody is jumping on this thread because nobody can tell the difference, largely because there is no difference.

    Just my two cents.


    Tuesday, May 3, 2011 4:31 PM
  • This site has a good example of Bridge: http://www.codeproject.com/KB/architecture/csdespat_2.aspx It has an example of a plane object which needs an abstracted way to fly. The implementation of flying could be different depending on the number of engines.

    This site has a good example of Strategy: http://www.dofactory.com/Patterns/PatternStrategy.aspx It has an example of the need to sort some objects, but you want to change the sorting routine at runtime.

    The difference between the two, I see, is that with the bridge example, my plane has to fly, but I do not know how to make it fly in advance, or I want to leave that exact flying implementation up to some thing else, or allow another implementation of fly to work for this object.

    With the sort example, the object has to sort. I just don't care how it sorts, or I don't want to embed the algorithm to sort inside my object.

    They both look the same on the surface to me as well. The main difference I see is the fact that in the Bridge pattern, the abstraction is PART OF the object, but in the Strategy pattern the abstraction is performed BY the object.

    The bridge is a structural pattern. The strategy pattern is a behavioral pattern. If you are concerend with decoupling the dependencies inside the object being used to build other objects, then you should investigate the bridge pattern. If you are concerned with decoupling the actions performed by your objects, then you should look at the strategy pattern.



    Tuesday, June 7, 2011 8:43 PM
  • Strategy pattern


    Strategy pattern (also known as the policy pattern) is a particular software design pattern, whereby algorithms can be selected at runtime.


    Bridge pattern


    The bridge pattern is a design pattern used in software engineering which is meant to "decouple an abstraction from its implementation so that the two can vary independently".[1] The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.


    Friday, June 24, 2011 8:41 AM