Design PatternHello programmers. This is the start of a series about Design Pattern. Design Patterns are a standard solution for problems you have to deal with every now and then. Especially pure object oriented programming (OOP) has shortcomings you need to handle somehow.
The right pattern in the right situation will help to produce code that is easily maintainable, understandable and has a lesser change to produce bugs.
The Strategy PatternInheritancelet's imagine we want a little bird simulation where we need every kind of bird behaviour. Our first idea might be to make an abstract class for bird that every sort of bird has to extend. Since we know that most birds can fly and swim, we implement those methods already. The method display is different for every bird, but has to be implemented by them, so we make it abstract.
Our first bird type is a dug, the second a swan. No problem with that. They can use the predefined swim() and fly() methods and only implement display().
Now we also want to add species like penguin, flamingo and ostrich. Those birds can not fly. Therefore they have to implement fly() to let it empty (if they inherit the default implementation they would be able to fly() which is wrong).
The penguin is also capable of diving. I configure this as a different type of swimming, so we override this method too.
An ostrich does not swim I think. This bird has to implement swim() and let it empty. The next problem is that it can run instead. So we need a new feature or skill for our birds: the method named run(). Now look at our diagram and say how many classes we have to change to implement the run() skill.
If we add 50 more birds like that implementing new skills will be a pain in the ass. Also we have a lot duplicated code, e.g. for all birds that can dive we override the swim method and implement the same code. That can not be a good solution. Let's think about another.
InterfacesWhat if we use interfaces, so we don't need to implement so many empty methods?
I somehow have the feeling this is even more complicated than before and it still does not avoid duplicated code.
StrategySince all we have done before is crap, we move on to the strategy pattern. We encapsulate now the behaviour instead of the bird types.
Design principle 1: Identify the variable aspects of an application and separate them from the stable ones.
Our actual bird class will look like this:
The methods might look like this (pseudocode):
performFly() {
fb.fly();
}
performSwim() {
sb.swim();
}The behaviour types are not fixed, so you can change the behaviour very easily on runtime. I.e. like this:
sb = new DiveBehaviour();
...
sb = new NormalSwimBehaviour();You might also notice that there is no duplicated code anymore and adding new features is easy.
To summarize a Strategy Pattern defines a family of algorithms, encapsulates every algorithm and makes it this way exchangeable.
Design principle 2: Composition is better than inheritance.
Sources: Notes from my study
Final note: I am not a bird expert and won't take any responsibility for wrong concepts about birds.
