“Design Patterns: Not for eating” – a response article

In the article “Design Patterns: Not for eating” the author’s explains his vision of the world of design patterns. According to him they are “off-the-shelf recipes for solving common re-occurring problems and also that they are good for raising a discussion regarding these problems”.

He agrees that they are useful in some cases, because nobody wants to “re-invent the wheel” but in the meantime he also thinks that the design patterns should be used by experienced developers only. The reason for that is because if an unexperienced developer doesn’t spend some time on thinking about the problem he or she has, applying the design patterns in this case will result in “missing out the well-trodden path“ which I understand as not gaining experience and knowledge from the particular problem.

I don’t really agree with this statement because of the following reasons:

  1. First of all I think that the author is contradicting with himself, because according to him the unexperienced developers should not use the design patterns. But if they don’t use them then they should come up with a new definition on how to “invent the wheel”. And this is not very desired because for an unexperienced developer this will be much harder than for experienced one. I believe that unexperienced developers should be exposed to different kinds of problems, but this doesn’t mean that everybody should learn CPL (Combined Programming Language) in order to understand C.
  2. According to me unexperienced developers should try to use as many design patterns whenever they can apply one (of course this depends on the given problem whether it allows a solution based on design pattern or not). The reason for that is because I see the design patterns as a manual for commonly occurring problems. I also think that the use of design patterns will significantly increase the complexity of the problem, because before implementing a design pattern, one should understand it very well. And increased complexity means that the problem requires more knowledge in order to be solved, but once solved the rewarded experience from it will be more.
  3. Another point is that I think of design patterns as a way of providing a common language for the developers with different levels of experience. The experienced developers in that case will be acting most of the time as teachers and the unexperienced ones will be their students. And if there isn’t a common language between teachers and students, the students won’t be able to make much progress. This is of course only related to the problems which can be sorted out with design patterns.

This of course is my opinion and it could be wrong as well. I am simply defending the design patterns, because some of them have helped me a lot while encountering different problems in the projects I was working on. During my first internship in a software company the first thing I learned was the Singleton Pattern which later on I used in many projects (from university and job-related ones through personal projects as well).