Before telling anything about design patterns i will explain the idiom “reinventing the wheel”. It means wasting time and resource in developing something that has already been developed and optimised.
Reinventing wheel is
So why am i telling this? and how is it related in anyway to design patterns?
Let me explain !
Design patterns:
Design patterns are optimised, ready made solutions to common problems in designing and programming logic. There are some common patterns for problems in design and coding(most of the time). If you have not noticed it till now, you will notice it soon when you start developing applications. For example, lets say designing a login page may have a problem. And this problem occurs in login page of every application you write. So if the problem has a pattern then why not develop an optimal solution and have it as a pattern too? Interesting right ?
Actually programmers and designers have identified such problems and developed many patterns which can be adopted so that you have an optimised design/code in your application. Those patterns are known as design patterns and we are going to see more about them in this blog. Welcome !!
I think now you should have an idea why i started this post by explaining what ‘reinventing a wheel’ is. Unless you are sure of a better solution for your problem , it is advised to follow design patterns already specified. If you try implementation of your own style( i'm not saying you shouldn’t ) you will most probably be wasting your precious time which can be better utilised to add or develop new things upon the pattern.
How do i know when to use? what to use ?
I personally feel that learning patterns won’t be helpful in anyway. Just know them. Applying design pattern comes instinctively for a good programmer. You may be using design patterns in your code without actually knowing the pattern.
What design pattern to use depends entirely on the problem statement and scenario. Think twice before you decide to use a pattern. Because using a wrong design pattern may be disastrous !!
Some common design patterns
If you search for all design patterns specified(by someone) you will find that there are 100s or even 1000s of design patterns available. But every pattern is not so unique and not so common. Only a handful of design patterns are common and frequently used.
Design patterns can be broadly classified into 3 fields... they are,
Am not going to explain any design pattern in specific as i have no experience working on them( may be i would have used them without knowing what they are !!) It tool experts years to understand design patterns fully. I cannot explain them in my first day of introduction to design patterns. Also there are lot of good websites explaining each design pattern in detail with examples. I will be checking out them in days to come ...
Criticism
There are some harsh criticisms on design patterns. I will tell a few here,
Refactoring:
It means making changes to code so that it's better than the previous version without modifying the behaviour. Better in the sense , the code is easier to understand and easier to extend in future. As far as i know Refactoring is a continuous process. You cannot plan and do it in a particular day/week(that may lead to complete mess sometimes).I feel the best practice is to refactor your code whenever you think refactoring possible, so that you won’t be building more lines of code on improper code.
SOLID principles:
SOLID --> Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion
Again, you can refer for definitions in any website explaining SOLID... here i will just give you a few examples
Single responsibility:
Suppose you buy a book to learn Hindi in 30 days. Will it be helpful if the book also has instructions on how to cook and these instructions are randomly mixed with your Hindi lessons ?? It would make the book unreadable and inefficient. Similarly a class in OOP should have single responsibility to make things easy and clear!
Open close principle:
Lets assume you are building a house. You build 2 floors and live for a year. After that you decide to build two more floors. You consult an architect... and he tells that your foundation is not strong and needs to be modified !!! that's rude isn't it ?? In a similar way modifying something for extension is not advised. It simply leads to loss of time and resource. A class should be open for extension and closed for modification!
Liskov Substitution:
I came across this very interesting example, if you have something that looks like a duck , quacks like a duck but needs batteries you probably have the wrong abstraction !!
Getting the concept??
In my post about inheritance i would have cited the example of inheriting a square from rectangle and explained why it is wrong. (because changeHeight method cannot be applied to square!) Today i understood that it’s violating the Liskov substitution principle(subclass should be substitutable in place of base class).
On encountering such problem you have to tweak the methods in subclass to some extend. (changeHeight can return a new rectangle object with modified height,or it can have no effect on square or it can change both height and width of square..etc..)
Interface segregation:
A laptop mostly has one or two headphone ports. Imagine if it has a 20 ports all similar to headphone ports but only one is the actual headphone port. Won’t it be difficult to plug in the headphone? So interface had to be simple and the way to acheive it is by using segregation.(Soln: headphone ports can be on one side only or they can be separated and put in some case like thing...etc...)
Dependency inversion principle:
Higher level modules should not depend on lower level modules. They should be abstracted. Confused? An example would make things clear. Consider you have a bicycle. It's chain has some problem and you decide to replace it. Now if your bicycle uses some function of the chain in its class without abstraction then you end up in trouble. A higher class should not directly use the functions of lower class. A layer of abstraction should be present so that lower class can be replaced easily if required !
Anti patterns or dark patterns or pitfalls
These are just solutions(negative solutions !!) for common problems which are poor or wrong or counter productive or ineffective.Hard coding,blind faith,copy paste programming etc etc.. there are many many such patterns. Read about them and am sure everyone of us would have used anti patterns some time in our code.
Thanks for reading my views on design pattern. Comments are appreciated. See you in next post !
Here is the audio blog of design pattern : Design pattern audio blog
Trained @ Sourcebits
Reinventing wheel is
- pointless
- adds nothing new of value to an object/practice
- a waste of precious time which could be used to develop more meaningful stuff
So why am i telling this? and how is it related in anyway to design patterns?
Let me explain !
Design patterns:
Design patterns are optimised, ready made solutions to common problems in designing and programming logic. There are some common patterns for problems in design and coding(most of the time). If you have not noticed it till now, you will notice it soon when you start developing applications. For example, lets say designing a login page may have a problem. And this problem occurs in login page of every application you write. So if the problem has a pattern then why not develop an optimal solution and have it as a pattern too? Interesting right ?
Actually programmers and designers have identified such problems and developed many patterns which can be adopted so that you have an optimised design/code in your application. Those patterns are known as design patterns and we are going to see more about them in this blog. Welcome !!
I think now you should have an idea why i started this post by explaining what ‘reinventing a wheel’ is. Unless you are sure of a better solution for your problem , it is advised to follow design patterns already specified. If you try implementation of your own style( i'm not saying you shouldn’t ) you will most probably be wasting your precious time which can be better utilised to add or develop new things upon the pattern.
How do i know when to use? what to use ?
I personally feel that learning patterns won’t be helpful in anyway. Just know them. Applying design pattern comes instinctively for a good programmer. You may be using design patterns in your code without actually knowing the pattern.
What design pattern to use depends entirely on the problem statement and scenario. Think twice before you decide to use a pattern. Because using a wrong design pattern may be disastrous !!
Some common design patterns
If you search for all design patterns specified(by someone) you will find that there are 100s or even 1000s of design patterns available. But every pattern is not so unique and not so common. Only a handful of design patterns are common and frequently used.
Design patterns can be broadly classified into 3 fields... they are,
- Creational
- Behavioral
- Structural
Am not going to explain any design pattern in specific as i have no experience working on them( may be i would have used them without knowing what they are !!) It tool experts years to understand design patterns fully. I cannot explain them in my first day of introduction to design patterns. Also there are lot of good websites explaining each design pattern in detail with examples. I will be checking out them in days to come ...
Criticism
There are some harsh criticisms on design patterns. I will tell a few here,
- Beginners or new programmers may try to relate every problem with some design pattern. Result of that is unnecessary complications in code
- Design patterns are just a result of good object oriented approach and SOLID techniques and code refactoring. I will explain what’s SOLID and Refactoring soon
- They are too generic and not language specific
Refactoring:
It means making changes to code so that it's better than the previous version without modifying the behaviour. Better in the sense , the code is easier to understand and easier to extend in future. As far as i know Refactoring is a continuous process. You cannot plan and do it in a particular day/week(that may lead to complete mess sometimes).I feel the best practice is to refactor your code whenever you think refactoring possible, so that you won’t be building more lines of code on improper code.
SOLID principles:
SOLID --> Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion
Again, you can refer for definitions in any website explaining SOLID... here i will just give you a few examples
Single responsibility:
Suppose you buy a book to learn Hindi in 30 days. Will it be helpful if the book also has instructions on how to cook and these instructions are randomly mixed with your Hindi lessons ?? It would make the book unreadable and inefficient. Similarly a class in OOP should have single responsibility to make things easy and clear!
Open close principle:
Lets assume you are building a house. You build 2 floors and live for a year. After that you decide to build two more floors. You consult an architect... and he tells that your foundation is not strong and needs to be modified !!! that's rude isn't it ?? In a similar way modifying something for extension is not advised. It simply leads to loss of time and resource. A class should be open for extension and closed for modification!
Liskov Substitution:
I came across this very interesting example, if you have something that looks like a duck , quacks like a duck but needs batteries you probably have the wrong abstraction !!
Getting the concept??
In my post about inheritance i would have cited the example of inheriting a square from rectangle and explained why it is wrong. (because changeHeight method cannot be applied to square!) Today i understood that it’s violating the Liskov substitution principle(subclass should be substitutable in place of base class).
On encountering such problem you have to tweak the methods in subclass to some extend. (changeHeight can return a new rectangle object with modified height,or it can have no effect on square or it can change both height and width of square..etc..)
Interface segregation:
A laptop mostly has one or two headphone ports. Imagine if it has a 20 ports all similar to headphone ports but only one is the actual headphone port. Won’t it be difficult to plug in the headphone? So interface had to be simple and the way to acheive it is by using segregation.(Soln: headphone ports can be on one side only or they can be separated and put in some case like thing...etc...)
Dependency inversion principle:
Higher level modules should not depend on lower level modules. They should be abstracted. Confused? An example would make things clear. Consider you have a bicycle. It's chain has some problem and you decide to replace it. Now if your bicycle uses some function of the chain in its class without abstraction then you end up in trouble. A higher class should not directly use the functions of lower class. A layer of abstraction should be present so that lower class can be replaced easily if required !
Anti patterns or dark patterns or pitfalls
These are just solutions(negative solutions !!) for common problems which are poor or wrong or counter productive or ineffective.Hard coding,blind faith,copy paste programming etc etc.. there are many many such patterns. Read about them and am sure everyone of us would have used anti patterns some time in our code.
Thanks for reading my views on design pattern. Comments are appreciated. See you in next post !
Here is the audio blog of design pattern : Design pattern audio blog
Trained @ Sourcebits
No comments:
Post a Comment