Post

Why Know Design Patterns?

Posted
By Ronald van der Bergh 4 min read

What is the “next level up” for a software engineer? The options are bewildering. Probably the first thing that comes to my mind is learning another programming language. Learning new programming languages exposes you to different ways of solving problems and adds a wonderful new tool to your toolbox. One should definitely know more than one! In their very insightful book The Programmatic Programmer, Dave Thomas and Andy Hunt suggest that one should learn a new programming language each year.1 But, just learning language after language might also result in a fairly superficial engagement with those languages. And that’s why learning some language-agnostic design patterns2 is a really good next step.

Why Know Design Patterns?

Programming is fundamentally about solving problems. But some recurring problems have already been solved; there is no reason to reinvent the wheel.

Those solutions are called “design patterns”, and they are based on years and years of programming experience. Most of these patterns were identified and collected in 1994, and they have changed surprisingly little over the last thirty years. They have changed so little, in fact, that the book that started it all, Design Patterns: Elements of Reusable Object-Oriented Software3 is still considered a standard reference work in the field.

Knowing these patterns will be helpful in at least three ways:

  1. When faced with a problem, you will be able to solve that problem in an efficient way in a shorter period of time, while keeping the system open for change in a less error-prone way. (Note: some of these patterns may take longer to implement, and then the emphasis falls on the second part of that statement: design patterns lead to more maintainable and extensible code.)

  2. When faced with someone else’s code, it will be easier to follow AND you will more readily recognize the nature of the problem that is being solved.

  3. Someone else will be able to follow the structure of your code (and this someone else might be yourself, six months from now).

Related to that second and third statements is the added bonus that naming these design patterns give designers a shared language to use to refer to them.4 This means it is easier to collaborate and discuss possible solutions.

How to Learn Design Patterns?

To learn design patterns, it is necessary to both study and experience them. Sometimes a design pattern can make sense and the code can be quite understandable even if a developer doesn’t know the name or details of the design pattern. This certainly happened (and still happens?) to me! It’s important to be able to recognize design patterns (see esp. points 2 and 3 above). And of course not knowing that the pattern exists will most likely mean that you will never implement that design pattern, so pure academic knowledge is also useful.

Study

For studying and learning more about design patterns, see the Resources section below. And for my own edification, I’m going to blog about different design patterns in the future. My plan is to describe the pattern, and then (for my own experience!) implement the pattern in C#. I will update this post with links as I do this, and of course the C# code will be in this public GitHub repo.

Experience

As for experience: unfortunately that’s just something that comes with time. But, it’s worthwhile to look at other code bases (and the code base you’re working on now) to try and identify design patterns - and of course, to start implementing them too.

Patterns

Resources

Here are three recommended resources for learning design patterns:

  1. Thomas, David and Andrew Hunt. 2019. The Pragmatic Programmer: Your Journey to Mastery. 20th Anniversary Edition. Pearson / Addison-Wesley. Page 15. ↩

  2. Design patterns are generally language-agnostic, but they might be tied to a specific programming paradigm). In this post, I’m focusing on object-oriented languages. ↩

  3. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. 1994. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional. ↩

  4. Freeman, Eric & Elisabeth Robson. 2021. Head First Design Patterns: Building Extensible & Maintainable Object-Oriented Software, 2nd Edition. O’Reilly. Page 28-29. To be clear, I’m not a big fan of technical jargon when it becomes a barrier to entry (and this isn’t what Freeman and Robson are suggesting, either!). However, there is a reason why subject-specific language comes into being. To keep to the analogy of the wheel: it’s much easier to say “wheel” than having to say “the round thing that turns around and around” each time. ↩

Learning
design patterns learning growth programming paradigms OOP object-oriented programming skill experience C# .NET
This post is licensed under CC BY 4.0 by the author.