In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
Wikipedia
Design patterns are some what similar to algorithms. A problem can be solved by a certain ways using certain algorithms. Algorithms gives ways to solve a problem. Some algorithms are considered better with respect to some criteria e.g. performance. And some algorithms are considered standard and the programmers are supposed to use them often. But the beauty with algorithms are that they are functions. They take some values as input and give some output. So algorithms can be easily coded into libraries and distributed as reusable components.
While designing complex and large systems the designers need to give a design that solves the problem at hand. In addition to it, the design should be extensible and maintainable. To develop a system specified by a set of requirements one can come up with a set of designs. Some of them will be considered better than other based on some criteria. The similarity ends here. Unlike algorithms, we can not pack design patterns and sell them as reusable components(though some people have tried to do so).
Advantages
1:- The patterns have been developed and enhanced by some of the best designers and while using patterns we are standing on the shoulders of those giants. We not only get nice solutions to our problems, we also get a solution that is tried and tested over the years. We may come up with a design that seems good in the initial stages, but at a later stage of development we may find problems with it. But by using design patterns the risk falls drastically.
2:- The design patterns are considered sort of a standard, which all the professional developers ought to know. So it increases the code readability. When we see something prefixed or post fixed by factory, suddenly we think about the factory design pattern. It also enhances the communication among designers and between designers and developers. Design patterns become a medium of communication in this case.
Disadvantages
1:-If all you have is a hammer, everything looks like a nail. After learning the design patterns, the programmers try to use them often. After all they have mastered something that some of their fellow programmers are yet to command. To show case their skills, they end up in over using design patterns. Design patterns often come with a performance penalty. And it may not be wise to use the design patterns in some designs.
2:- As mentioned above, design patterns come with some performance penalty.
3:- The program using design patterns often becomes larger. Also the program at times becomes difficult to understand for programmers not having design pattern knowledge.
My thoughts on Design Patterns:-
1:- Design patterns solve design issues. So they are not dependent on any language. You can use any language to implement a design pattern. But some language with certain features can make some design patterns unnecessary or easy to implement. One beauty of design pattern is that the skill is not based on a specific language and hence a great asset for a developer.
2:- Another important thing about design pattern is that the patterns are developed by designers over the time while designing complex and large systems. So developers with less experience often fail to fathom the true value of the design patterns. In my case, I have come to understand their value better after both experience and revision. I have weakness with comprehension. I never get things in the first go. It is while revising the things that I understand more and more about them.
3:- While learning design patterns, developers should concentrate on the techniques like introducing another in-direction. Because the techniques are crucial which can enable us to develop more design patterns or better designs in our career ahead. Also it enables us to develop a sort of meta-thinking.
4:- And another personal experience, never ever start learning design patterns with the GoF book. It is not easy read. And the best place to start learning about design patterns is …………Wikipedia[:)]. The articles are easy to comprehend. Off course you need to learn the GoF. It is a classic book and it has more substance than Wikipedia entries (till now as Wikipedia entries are supposed to be enhanced over time). But one should better read the GoF only after going through the Wikipedia pages.
Comments
Jim says:
Excellent analysis. Your thoughts match mine almost exactly.
I’ll add one more that I’ve found helps explain them to those who just can’t figure out what they are.
Design Patterns are to Object Oriented Technciques as Data Structures are to Procedural Techniques.
Data structure use recurring features, such as memory allocation, pointer manipulate and algorithms, to create stacks, queues, lists, trees etc. The same primary pointer techniques are used in all of these structures, but by focusing upon what as well has how they are implemented, we move one step higher in functionality.
Design Patterns do the same thing in OO. There’s nothing really new in Design Patterns as far as implementation is concerned, but from a conceptual point of view, we’re at least one, two or more levels higher.
I’ve seen a lot of negative press on the internet about design patterns, but most of those arguments would apply against data structures as well.
+ Since you have to implement a design pattern (data structure), the real problem is a deficiency in the coding language.
+ The implemenation is too confusing to those who don’t understand design patterns (data structures). (I defy any novice to understand a circular double linked list from the code alone. Same goes for visitor as well.)
Soubhagya says:
Jim, thanks for your valuable insights. I also agree with them.