6 Replies - 2767 Views - Last Post: 10 May 2013 - 06:35 PM

#1 lucky3  Icon User is offline

  • Friend lucky3 As IHelpable
  • member icon

Reputation: 231
  • View blog
  • Posts: 765
  • Joined: 19-October 11

Design patterns: Strategy and Bridge - the difference

Posted 25 April 2013 - 07:08 AM

Hi. I'd like to clear up my doubts about the difference between Strategy and Bridge design patterns.

Strategy: (behavioral pattern)

Quote

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.


Bridge: (structural pattern)

Quote

Decouple an abstraction from its implementation so that the two can vary independently.


I hope my understanding of Strategy pattern is correct (I apologize for stupid example) with this C# code:
Spoiler


For the sake of simplicity, there's just different string returned from each strategy, but would represent totally unique algorithm for each fighting strategy in real world application.

Would the Bridge then be just abstracting Knife to Weapon base class (or IWeapon interface), and use its different implementations? Is this the point of Bridge?

Example of my Bridge understanding:
Spoiler


Is that it? Only extracting some interface (or create base class), and potentially have several implementors of this abstraction (IWeapon in this case), using some other abstraction (IFightingStrategy)? Or am I missing something here? Please, correct me using the same classes (if possible) in your example.

This post has been edited by lucky3: 25 April 2013 - 07:13 AM


Is This A Good Question/Topic? 0
  • +

Replies To: Design patterns: Strategy and Bridge - the difference

#2 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Design patterns: Strategy and Bridge - the difference

Posted 04 May 2013 - 10:54 PM

I'll take a crack at using your Knife example. You have different fighting strategies with knife: stab, slaughter, cut. The strategies are selected at runtime, i. e. you use the functionality in different ways during the fight. But let's say that you have three kinds of weapons: knife, sword, and spear. Each has stab, slaughter, and cut, each implemented in their own way. Now you have nine permutations, three ways to use each of three weapons. You could have nine weapon strategies, or you could choose to have two different interfaces, one for weapon and one for fighting technique, and bridge the two together using aggregation. That's the bridge pattern, and the decision is structural. You also have six concrete classes instead of nine.

The analogy of normalizing a table of data into first normal form might be useful.

Also, this is a succinct little diagram of where the bridge pattern is useful.
Was This Post Helpful? 1
  • +
  • -

#3 lucky3  Icon User is offline

  • Friend lucky3 As IHelpable
  • member icon

Reputation: 231
  • View blog
  • Posts: 765
  • Joined: 19-October 11

Re: Design patterns: Strategy and Bridge - the difference

Posted 06 May 2013 - 06:17 AM

Thank you Bob. So my last paragraph in initial post (IWeapon interface), and last method in posted sample code of "my understanding" is actually representing the Bridge pattern? I'm using MachineGun and Knife (instead of Knife and Sword & Spear) with IWeapon interface, each using IFightingStrategy. I guess we're talking about the same with different weapons using fighting strategies.
Was This Post Helpful? 0
  • +
  • -

#4 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Design patterns: Strategy and Bridge - the difference

Posted 06 May 2013 - 11:04 PM

<So my last paragraph in initial post (IWeapon interface), and last method in posted sample code of "my understanding" is actually representing the Bridge pattern?

I wrote something that seems wrong, and I'm getting sleepy. I'll get back to you on that. :)

This post has been edited by BobRodes: 06 May 2013 - 11:48 PM

Was This Post Helpful? 1
  • +
  • -

#5 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Design patterns: Strategy and Bridge - the difference

Posted 07 May 2013 - 06:16 PM

Ok. The way I see the application of Bridge pattern is that you have on the one hand some weapons and on the other some techniques. All the weapons have the same techniques. That's why I used Knife and Spear. Taking http://en.wikipedia..../Bridge_pattern as an example, Weapon is the Abstraction class from the Bridge diagram. RefinedAbstraction classes are WeaponKnife and WeaponSpear. Implementor class is Technique; ConcreteImplementors are TechniqueStab, TechniqueCut and TechniqueSlaughter.

So, Weapon has a property which is a reference to a Technique object, and Weapon's constructor has a parameter that's a reference to a Technique instance; the property gets set equal to the parameter in the constructor's code. That's how the Aggregation association is set up, and that's the Bridge. The client instantiates a weapon (or both), and instantiates the Concrete technique objects. In order to switch techniques, the client alters the value of the Weapon object's property to be a reference to a different technique object.

Now, your example differs from this in that it has two weapons that don't share the same techniques. While you can do this, it doesn't leverage the advantage of the pattern, which is a way of taking two sets of related but orthogonal classes and avoiding the excess of combining all the permutations of each into one set of classes. In this case, you only turn six classes into five, but if you had three weapons and five techniques you would turn fifteen classes into eight. So this pattern is a more scalable way of dealing with two sets of related but orthogonal classes.
Was This Post Helpful? 1
  • +
  • -

#6 lucky3  Icon User is offline

  • Friend lucky3 As IHelpable
  • member icon

Reputation: 231
  • View blog
  • Posts: 765
  • Joined: 19-October 11

Re: Design patterns: Strategy and Bridge - the difference

Posted 08 May 2013 - 11:36 PM

Ah, OK... So if I just add Spear class, implementing IWeapon interface (probably IWeapon should have some method or property with IFightingStrategy interface in it, so it would actually enforce the Bridge, but not necessary), then when Spear uses the same concrete implementation of fighting strategy (say KnifeStabbingStrategy - here I should have better name like StabbingStrategy only) as Knife, that would represent the Bridge between different refined abstractions of IWeapon, and concrete implementors of IFightingStrategy. So in my example of "understanding", I was missing different consumers of the common concrete implementor, to actually use the Bridge. I've had it set up, but not used the Bridge.
Was This Post Helpful? 1
  • +
  • -

#7 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Design patterns: Strategy and Bridge - the difference

Posted 10 May 2013 - 06:35 PM

View Postlucky3, on 09 May 2013 - 01:36 AM, said:

So in my example of "understanding", I was missing different consumers of the common concrete implementor, to actually use the Bridge. I've had it set up, but not used the Bridge.

Different consumers of the common ABSTRACT implementor; each one using a different concrete implementor.

The more I look at my example, the less I like it. Weapon and technique just aren't orthogonal enough. Here's a better example:

Weapon abstract class, with concrete Sharpen() method and abstract applyTechniques() method. Weapon also has a concrete property cTechnique, which is a reference to a Technique object. applyTechniques uses this reference when calling methods on the Technique object.

Technique interface, with Cut(), Stab(), and Slaughter().

Knife and Spear each extend Weapon, implementing applyTechniques() in ways specific to their weapon type, calling the three Technique methods in various combinations. NinjaTechnique and SamuraiTechnique both implement Technique.

Client pseudocode:
Weapon aKnife = new Knife
Weapon aSpear = new Spear
Technique ninjaDo = new NinjaTechnique
Technique samuraiDo = new SamuraiTechnique
aKnife.sharpen()
aSpear.sharpen()
//so, here are the permutations:
aKnife.cTechnique = ninjaDo
aKnife.applyTechniques()
aKnife.cTechnique = samuraiDo
aKnife.applyTechniques()
aSpear.cTechnique = ninjaDo
aSpear.applyTechniques()
aSpear.cTechnique = samuraiDo
aSpear.applyTechniques()
There. I like that better. :)

Here's a UML diagram I knocked together:

Posted Image

This post has been edited by BobRodes: 12 May 2013 - 12:18 PM

Was This Post Helpful? 0
  • +
  • -

Page 1 of 1