Web Technology

Today I will talk about a simple pattern called Strategy Pattern. Strategy Pattern is influenced by the design principle "The aspects of your application which vary should be separated from the aspects which does not vary".
Suppose you are designing a Gaming Application where you have many characters viz., King, Queen, Knight and Troll. Each character can make use of one weapon at a time, but can change weapons at any time during the game.

If you analyze the application, the obvious design solution would be to have a class named Character, where fight() would be a method. But since each character has a different style of fighting, we will have to make separate classes for each character, implementing the fight method on their own. The class we identified named character, will have to be declared as an abstract with fight method declared abstract. So, now all the character classes identified will inherit this abstract class, Character.
Now let us focus on our next requirement. The next requirement is that each character can make us of one weapon at a time. So we can think of identifying the weapon for each character and make one weapon an attribute of each character class. The possible weapons could be Knife, Bows & Arrow, Axe and Sword. Now let us fix one weapon for each of these classes and let their fight() method use 'em. OK, looks fine.
Opps!...but we missed one of the important requirement, which is..."the characters can change their weapon at any time during the game". Oh!...that's bad.... Well now things looks difficult. Let us analyze it again. OK, we read earlier in this article that one of the design principle states that we should separate the aspect of our application which changes. Let us try using this concept. Here we see that the weapons are changing all through out..but rest of the aspect stays on... so we will now prepare a separate set of classes for weapons and then link these weapon classes with our character class with a "Has-a" relation. Well, to do this let us follow one more design principle which states that "never program to an implementation..program application to an interface".
So we set an interface named Weapon, which declares a method named UseWeapon(). All weapon classes implements this interface viz., Knife, Bows & Arrow, Axe and Sword. Now we link this interface to our character abstract class to draw a "Has-a" relation. This will give our Character class enormous capability to dynamically change weapons.
Now our character class has an attribute defined of type Weapon, which can be at run time set to any of the weapon classes. We also implement a method named SetWeapon() in our abstract class. Now our classes looks like this..



So now all our concrete classes can use this.objWeapon in fight method and allow the weapon to be changed at run time.

Let us see one of the possible implementation

Character objCharacter = new King();
Weapon objKnife = new Knife();
Weapon objSword = new Sword();
objCharacter.SetWeapon(objKnife);
objCharacter.fight(); //fighting with Knife now
objCharacer.SetWeapon(objSword);
objcharacter.fight(); //now fighting with a sword

This is how we implement Strategy Pattern. Let us now see the formal definition of this pattern. The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Now you are armed with yet another pattern. That's all for the day...please do let me know, what you think about this pattern.....Looking forward to your comments......Bye for now...

Labels: Design Pattern, Object Oriented Programmming, Strategy