Design Patterns – To Use Or Not To Use

One of the problems of the fresh programmers today is that they get to hear a lot of contradictions, from equally credible people, on various topics in programming. One such controversial topic is use of GoF Design Patterns, especially the ones talked about in the book by GoF. This puts these programmers in a dilemma as to whether they should read and adopt what is professed in the book or not. Or do design patterns create more problems than solve them?

Here are my thoughts.

Most of the times the argument against the GoF design patterns is that they are not reusable across types, and you end up rewriting a lot of code. Reusability is lost. However, this is mostly limitation of the language. C++ is a popular example used. C++ has its limitations, and hence the value of these design patterns is higher when compared to the others. An interesting thing to try is to remove the language from the equation, and understand the concept instead of the implementations. The Iterator design pattern, that gets bashed up often, makes you think about what if we could talk to the containers without having to know their details. I think this idea itself is so valuable that it can be applied in multiple cases in multiple ways. An associated problem with this is that some of the other programming elemnts get ignored. For example, it is important to consider multiple aspects like scope, lifecycle and threading while designing a Singleton class.

The discussion also usually leads to a language war, as to which language is better than the other. Which cannot be anything but a personal preference. The choice of a programming language includes many more factors, and even in the recent times we have seen that languages like C and C++ could not be completely eliminated. The point is that value of a pattern’s implementation might vary by language, but the concept is still valuable.

I do agree with Jeff Atwood when he says that sometimes there might be simpler solutions available. I also agree with Mark Dominus that programmers can very easily succumb to the cut-paste habit. Also that Christopher Alexander’s idea has not been completely expressed by the GoF patterns book. Maybe it will be worthwhile to not compare the two efforts because they are quite different. Christopher Alexander authored “A Pattern Language”, while the GoF patterns book is about “Design Patterns – Elements of Reusable Object Oriented Software”. The former is more about creating a language that can promote commonality in design, whereas the later is more about the patterns themselves. I think building a language is more universal. But the concepts presented in the GoF book are no less useful.

I think Design Patterns should not be used out of habit, but because of conscious realization of their need. Nor are they just blocks of code. They are product of a process for identifying recurring problems and building reusable solutions, which might result in different implementations depending on the programming environment. Also, GoF patterns were written when the popular languages, and popular programming paradigms were different. There is no way I can apply any of the design patterns directly in any of the functional programming languages. It will be more harmful than useful.

If you are still a C++ fan, you should read Andrei Alexandrescu’s Modern C++ Design, which can give you a modern idea of design patterns can be applied in C++ through policy-based design. However, it is important to acknowledge that to make your design patterns knowledge portable you have to understand the underlying concepts, so that you can build more native implementations.

Discussion [Participate or Link]

  1. Teemu said:

    Have a look at the book Refactoring to Patterns by Kerievsky for a really good idea: instead of implementing patterns in your code from the beginning (and possibly complicating your design unnecessarily) only refactor towards them later, as soon as you see the real need.

  2. Abhijit Nadgouda said:

    Teemu, thanks for the tip. I agree with you completely, refactoring for design patterns is better most of the times. I remember, one of my colleagues used to call it injection 🙂

  3. Design Patterns As A Guide, Not A Toolkit | iface thoughts said:

    […] have gone through a cycle, where I worshipped them, then realized that they too had pitfalls, got confused, and now I realize that perhaps I completely misunderstood […]

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.