We do not need Design Pattern, we need the concept

Design Patterns are getting popular in recent decades. Most of the employers would ask questions about design pattern in the interview with applicants. It seems to be an essential skill that software developers must have to find a good job. Most of the companies are more or less using some of the design patterns in their products because it can bring them huge advantages. However this article tries to explain that design patterns are not almighty and understanding the concept behind design pattern is more important than knowing how to apply them.

Why to use design pattern

Software usually consists of tens of thousands lines of codes. Code consists of two parts, data structure and algorithm to implement some functionality. Software also consists of two parts, codes and design pattern. A complete software will integrate those small pieces of code to make them work together and this how would different piece of code be organized and designed to cooperate to deliver a complete system is a reflection of design pattern. For the same problem different people may have different ways to organize their code,logic to solve it. Design patterns are reusable standardized solutions to typical problems that frequently occur. They have proven to be the optimal approaches to solve specific problems.Apply the existing design pattern means one does not have to work on a problem that has been already solved by others. Also design patterns are useful in creating a shared vocabulary in a large team[1].

It’s very hard to use design patterns appropriately

Even though we can benefit from applying design patterns in our projects, it is very difficult to use them appropriately. People are very likely to fall into a trap that they want to use a design pattern not because it can solve the problem but simply because they can use it. It happens a lot to novice developers who fell in love with design patterns because of the beauty of the excellent design or obsessed with the feeling that they are being professional. This attitude will normally lead to abuse of design pattern. Applying the wrong pattern or needless pattern will unnecessarily increase the complexity of the code and increase the cost for testing and maintenance etc. Also there are criticisms on design patterns saying that the emerging of design pattern is a sign of lack of corresponding feature of programming language/framework. For example the Singleton, can totally be replaced by developing a new feature of any programming language to ensure there is only one instance of given class.

What do we actually need from design patterns?

As I mentioned in above section, sometimes developers use design pattern even when they do not understand why they are using it. Then it comes to the question that when to use the design pattern or what do we get from design pattern. To me it is the concept behind patterns which is important rather than the actual patterns. When it comes to the real software development, chances are the real problem we are facing usually is very complex and do not fit with any single existing pattern. With the knowledge of concept behind the patterns, we can accordingly modify/combining the existing design patterns to cater to the specific requirements. Design patterns are like a set of screw drivers of different shape and size. We need to know how to create one rather than how to use one because the bolts’ size are all different. We may find a suitable one but not a perfect one.

It is not all about design pattern

Software is not all about design patterns and there are lots of other things we need to take into account, for instance performance,maintenance cost and testing etc. Sometimes applying a design pattern can create decent and clean code but we may need to sacrifice for other reasons. For example, if you are developing a web-system to generate analytical chart for users. You may want to apply a template pattern to achieve a better code re-usage, which means code on the server side to generate the chart and only return the chart to client. However in reality no people would do that because the server has to do the work of both filtering data and generating charts. That will increase unnecessary burden on server. One would possibly do is to put the presentation on the client side code, so the server only need to filter data and let the client side to generate chart based on the returned data. This would possibly lead to some duplicate codes but it is necessary cost to achieve better performance.


In this article I have shortly describe what is design pattern and its advantages. Then I tried to convince the readers that it is very hard to fully understand design patterns and apply them appropriately. Furthermore I made the point that what is valuable to us of design patterns is its concept. Understanding of the concept is required to avoid abuse of design pattern and to make more reasonable design given a specific requirement. As a conclusion, it is good to know design pattern but do not attach to it. It is just a set of general approach to certain problems, not a big deal. Do not treat it like something you can show off then it will be very useful.


[1] Allan. http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/415

[2] Design Patterns wiki page. http://en.wikipedia.org/wiki/Design_Patterns

[3] The pros and cons of adopting and applying design patterns in the real world. M.P. Cline. Communications of the ACM, 39(10):47-49, October, 1996.

[4] Design Patterns: Elements of Reusable Object-Oriented Software Gamma, Helm, Johnson, and Vlissides 1995, Addison-Wesley, ISBN 020163361X.