Reading blogs on the Internet is a good way to keep updated on what happens in the industry and to get short introductions to specific topics. When it comes to deeper, elaborated analysis however, there is nothing as a good book. The single book that has meant the most to me within coding is the now classic Design Patterns: Elements of Reusable Object-Oriented Software by GoF (the Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides).
The book is made of up six chapters, with the first one being an introduction to the concept of design patterns and the second containing a case study of a “pattern view” on a sample application. The last four chapters are a catalog of design patterns. The entire book is a must read for any software developer.
The Design Pattern Introduction
I assume that most readers of my blog are familiar with the term design pattern. Even if you are, I recommend you to read the first chapter in the GoF book if you haven’t done before. It is a short, complete introduction to the concept of design patterns. Remember that when this book first came out, it was groundbreaking. Design patterns was not a well known concept, this is the book that essentially started the entire movement. The first chapter not merely introduces the design patterns concept, it defines what a pattern is by listing four essential elements of a pattern:
- The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two..
- The problem describes when to apply the pattern.
- The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations.
- The consequences are the results and trade-offs of applying the pattern.
I first read this book when I took a graduate level course at university (yes, ten years ago this was not part of undergraduate curriculum). After having read the introduction, I dived into the pattern catalog and found not only a set of well thought-through solutions to common problems but also the opportunity to study how experienced software designers where utilizing object orientation.
Non Tangible Classes (Strategy and Command Patterns)
The first thing that struck me was that classes don’t have to correspond to tangible elements of the design. Until then, my classes had either been representations of business entities (eg. Car, Person, House, Invoice) or of software concepts (e.g. File, Directory, UserAccount, Console, NetworkSocket).
The strategy and command patterns opened my eyes to the concept of classes being modeled out of software design concepts within the program. A strategy class can e.g. represent a layout algorithm. It is a very powerful concept that I now both see in existing code and utilize myself, without implementing the command or strategy patterns exactly.
Inversion of Control (Template Method)
The next major inspiration was that of inheritance and inversion of control. Previously I had occasionally used inheritance to either customize existing classes (by overriding them) or by opening up my own classes for reuse as a base class. With the template method I found out about the inversion of control concept (although I didn’t know it by that name back then). With the template method pattern a base class is not only possible to subclass. It is required to subclass it to use it. The base class only defines a skeleton, or template, of the behaviour. The actual details are filled in by the sub classes.
What GoF Meant to Me
To me, GoF opened up my eyes to the power of object orientation. The patterns in the book are concrete advice on how to solve specific problems (although a few are outdated 15 years later). Knowing the basic patterns definitely improves communication within a team when design patterns are encountered in the wild.
The patterns are also a great way to look into the minds of some great software designers. That’s what gave me the most knowledge; not only the basic set of patterns, but the greater understanding of how object orientation can be used.
The book is a must have in the book shelf for any serious software developer. If you don’t have it, go buy it now.
The links to Amazon in this post are sponsored.
I reread the GoF book every 2-3 years. Each time reaching a new level of “aha”.