In this article, we ‘ll learn how and when to use the design patterns.

we ‘ll be looking into strategy pattern. Before

diving into the world of design pattern we must have knowledge of OO design principles.

Here instead of getting started with the definition of strategy pattern and then explaining it.we will be looking into
the problem and try to find the solution for it.

We will be starting with the simple game application named a Simple SimUDuck App. The game can show a large
variety of duck species swimming and making quacking sounds. Developer’s while designing the system used OO
technique and created a base class as Duck and all other duck classes inherit it from a base class.

//sample code for the inheritance.

all things where set good with the application but there is a little CR(Change Request) from the users that some of
there duck should fly…., yes you heard right some of the duck should fly so welcome to word of programming and
gaming. Here everything is possible.

so what’s the big deal with it just add a fly method to the base class. And we are done for it….. after some time when
the game presented in there release every duck is like a superman flying in the air.
Again here only respective duck should fly not everyone. Here the only solution comes to our mind is to override the
methods and do nothing for the duck’s who are not superman.

//sample code for override method.

Just imagine the code changes and time required for a programmer to maintain and remember which duck to fly. so
here it is just one method just have another method Quack(). You would be thinking that is no big deal every duck
can Quack… but let think of it what about rubber and wooden duck. Just think about this below poor guy they can’t
quack or fly. Now you will think of just go and override the methods but how many time you will override this will be
the biggest nightmare for the maintenance.

So… let's give a thought about the interface. And try we can remove the method fly and quack to respective
interface and use them where it is necessary.

//code for the interface

is interface a good idea? For time being it is good we have just covered our half of the journey but we still have to
do code maintenance and change our code.

At this point, you might be waiting for a Design Pattern to come riding in on a white horse and save the day. But
what fun would that be? No, we’re going to figure out a solution the old-fashioned way—by applying good OO
software design principles.
Let's recap till now what are the weapons we have utilized to win this war? Inheritance and interface.

As we saw both the approaches, they solve half of the problem but there is a lot of code maintenance. So why don’t
we get the help of the design principle?

So we take out and abstract the behavior’s what varies that won’t affect the rest of your code. We know that fly()
and Quack() methods are the part of duck that varies across the duck.

// so the sample code behavior.

So let’s integrate the above code with our duck class

// sample code for duck

// show some implementation fo