Design pattern… I have been studying design patterns for a while and I would say that one needs some patience to studying design pattens , because its not a technolgy that you are learning rather its a sort of art that you are trying to expertise. All of us want instant returns when we spent time over anything. It is very different from reading spring , struts, hibernate or other technologies/frameworks on which when you invest say two to three hours and come out of it in a state where you can say that I learnt transactions handling, or concrete mapping or cascading or validation framework.There is no such kind of things
in desing pattrens , it is something which all of us know but we have to get used to doing it in an appropriate way. And believe me when you try to apply those design patten in you work after reading ,you may feel the difference in the way you used to think and your current thinking approach. Although it may take some time.
So what actually is design pattern? Well design pattern is you can say a set of different object oriented approach which has been used and practised by developers over the time to solve differnt problem keeping the maintaibilty of code to minimum and flexibilty of code to maximum.Infact maintaibilty and flexibilty of code vary inversly to each other.So what is flexibilty of a code? Flexibilty of a code can be thought of as the easiness to introduce new requirements in your application without changing the existing code. The less you change the existing code , less are the chances of new bugs introduced and
hence lesser the maintainability issues.
I don’t know any design pattern yet I never faced any problems. Then why should I go through allthese design patterns?Yes , there is nothing that cannot be done without knowing design patterns.The answer to this question can be described as that knowledge of design patterns helps you in developing a design which can be altered at any time , that is not very tightly coupled and is quite flexible.Infact design patterns provide you
a base on which you can think , try out and find solution for your needs. When given a problem , if you just think of a solution then there are good chances that you may come out with a code that fits to your current needs but you may get stuck in future.
So when you try to solve these problem with some patterns in my mind you can see foresee those problems as to what is the thing which may create problem. So , you keep on thinking for the best solution.And its not necessary that you apply some design pattern in the end but you to an extent put a check on risk which may occur in future.
Now we can discuss these design patterns one by one in detail and here I would go with one of the most fundamental design pattern
Strategy pattern by definition says:
“Define a family of algorithms, encapsulate each one, and make them interchangeable. [The] Strategy [pattern] lets the algorithm vary independently from clients that use it”.
That’s definition but how do we achieve this. Well to promote client to choose from different implements we need to use HAS A relationship over IS A relationship.
The HAS A relationship promotes loose coupling . Inheritance promotes code re-use but but it also sometimes makes your code very tightly coupled which in turn makes it difficult to change the code.It also makes it possible to make changes without affecting the existing code.
So, the strategy pattern says that keep the IS A relationnship to only those part of the object which is not going to vary much in future.For those part where code may be varying you must use HAS A relationship so that depending on the varitaion you can inject the suitable implementation.
Let’s take an example .
Suppose I have an abstract class A . It has methods methodNotvaryMuch and methodVaryMuch.As the name suggest first method does not vary much while the second
varies a lot for differnt sub classes.Now I have say 20 subclasses of classes A which are using default implementation of two methods.One day I get a requirement that I need a different implementation for methodVaryMuch for 5 subclasses. So what I have to do is go to each of the five subclasses and override their methodVaryMuch , writing the same code in each class and edit my exisiting code.After few days I got to know have to add one more line to those code changes, again I have to edit those classes.
Now, Think we have that methodVaryMuch behaviour decalred in an interface and my base class has a reference to this object.
So in this case at start there would be one concrete class implementing interface which declares methodVaryMuch and base class has a referenceto it so do the sub classes.
Now for the changes described what we have to do is just create a new concrete class with new methodVaryMuch implementation and all the sub classes for which we need changes we need to change the reference to new interface implemention. It does not require chaning existing code.
This gives greater flexibility in design and is in harmony with the Open/closed principle (OCP) that states classes should be open for extension but closed for modification.
The Strategy pattern embodies two principles , encapsulate the concept that varies and program to an interface, not an implementation. Here in the example we have coded to interface which has enabled us to swap the implemention for change required class with different implemetnation.
So, I guess this is all about strategy pattern , and let me get into the next pattern Observer pattern for my next blog.