Strategy pattern is mainly used for composition rather than inheritance. It defines a family of algorithms encapsulates each one and makes them interchangeable. Strategy makes algorithm change independently without client changing it. Strategy decouples algorithm from the client using it which means if I have to change the algorithm, I don’t have to change the client code calling it.
Example:
Let’s say We have a Duck Super class and other classes inherit from this class. The below example shows WildDuck and CityDuck implementing the Duck so they have their own methods of Display, thus wild ducks can be displayed differently from city ducks and the behavior of Quack is shared between sub classes using inheritance for code-reuse. This is good if there are no new requirements.
But for example, let’s say we have a new requirement to add a flying behavior for these ducks which turns out adding fly in superclass and sharing it across sub classes. This is where it becomes messy if we have a new type of duck which cannot fly, we are forcing it to implement the behavior. Of course, we can override and throw exception but that’s not how ideally it needs to be designed. Following example shows RubberDuck class having its own flying behavior which is essentially NoFly.
Similarly let’s say we have a mountain duck which has its own flying behavior, but it is different from Rubber Duck flying behavior but its same as CloudDuck Flying behavior which now makes code duplication.
It works as long as the behavior is shared downward like in a tree hierarchical manner but whenever we want to share the behavior horizontally, we cannot go with inheritance downward. This is where strategy pattern helps, in our example we have algorithm for quacking and flying and what we realized is we can’t create hierarchical solution to share the algorithms.
Implementation
We can use strategies for quack and fly such as IQuackStrategy and IFlyStrategy which are interfaces and there can be different concrete implementations of each of the interfaces like SimpleQuack and NoQuack as shown. Every Duck class which has an IQuackBehaviour will have their own concrete strategy quacking behavior. Now these concrete strategy algorithm implementations can vary independently from the client. Now the Duck class doesn’t need to care about the quacking, it only needs to take care that every instance of duck has concrete implementation of quack behavior. Below class diagram shows the complete redesign implementing strategy pattern. Every Duck Class has an IQuackBehaviour, IFlyBehavior and IDisplayBehavior. Each of these interfaces have concrete implementations of strategies which are passed to the duck class which makes the strategies to vary independently from the client.
UML
Below is an UML diagram. In our example Client is a Duck class having Quack, Fly & Display behavior. The execute method in client calls run method of the corresponding strategy.
I didn’t get to go to my regular gym today but I for the first time went to my apartment gym and found out it is decent too. :-p
#3DaysOf100DayCode #3DaysOf100DaysFitnes
Comments