Design Patterns – A review

I recently finished reading “Design Patterns: Elements of Reusable Object-Oriented Software” by Erich Gamm, Richard Helm, Ralph Johnson, and John Vlissades. Due to its popularity, the length of the title, and the fact that it has 4 authors, it is affectionately known as the “Gang of Four” book or GOF for short.

Another book I should have read years ago

When I reviewed Steve Watt’s book, I referred to it as “The software engineering book I should have read 10 years ago”. I feel the same way about this book.

The information contained in this book would have been very useful when I first began using Object Oriented Programming (OOP). When first learning about OOP, the ideas of inheritance, polymorphism, composition, aggregation, etc were very abstract to me. I was able to understand what the terms meant, but understanding how all the different concepts related was very difficult. For some of the concepts, it was also difficult to see their usefulness.

GOF does a very good job of showing how to put all these OOP concepts to use. Each pattern uses some combination of basic OOP principles to accomplish a particular goal. Seeing a concrete use for these abstract concepts was really useful.

Another aspect of the GOF that I found very useful and transformational was its use of not just inheritance but also composition. It has been a while since I took the NI OOP Class, but from what I remember there was definitely more emphasis on inheritance than composition. GOF actually emphasizes composition more, which I found interesting. Right at the top of page 20 GOF states the second principle of object-oriented design:

Favor object composition over class inheritance.

Had I followed that advice, some of my earlier object oriented designs would have turned out much differently.

The other key concept I took from the book is:


Encapsulate the part that changes.

This phrase is used a lot during the case study in chapter 2. A lot of the patterns make use of this idea.

Not Light Reading

While GOF does not appear to be very thick, it is certainly not light reading. Some books one can read straight through from start to finish. Doing that with GOF is quite difficult. The book is broken into four sections.

  • Introduction – Discusses where the patterns come from. Gives some general advice on how to pick which pattern to use. Explains how the book is organized.
  • Case Study – Uses the design of Document Editor to illustrate several of the design patterns. It discusses the decision-making process behind deciding which design pattern to use. It also shows how some of the design patterns work together.
  • Design Pattern Catalog – Contains detailed information for each of the patterns.
  • Conclusion – Talks about how to integrate design patterns into your development process.

The Introduction, Case Study and Conclusion are very readable. The Design Pattern Catalog itself is not. It’s meant as more of a reference section. The intention is that you use the introduction to get an idea of which patterns might be useful to solve your specific problem and then lookup those specific patterns in the catalog.

I should note that the book makes wide use of UML Diagrams to describe the various patterns. If you are new to UML you should check out Martin Fowler’s book on UML.

Catalog Layout

The description of each pattern is laid out in a similar manner. This makes the book really easy to navigate and makes it easy to compare the various patterns. This is necessary because many of the patterns are related. There is a graphic on the inside cover that shows how they are all related.

Each pattern entry contains the same 13 elements, which are outlined on page 6. By far for me the most useful sections were the Intent, Motivation, Consequences, and Related Patterns.

  • The Intent section is just a simple sentence or two about what the pattern tries to accomplish. It does a great job of summarizing the pattern.
  • The Motivation section is an example scenario where you would use the pattern. It provides a concrete example that shows how all the objects in the pattern interact.
  • The Consequences section talks about design tradeoffs. It also talks about potential problems you could run into.
  • The Related Patterns section is really interesting. It talks about similar patterns, the nuances between them, and why you might choose one over the other.

Application

Knowledge is great, but being able to apply that knowledge is even better. There are 2 sections of the book that I photocopied and put up on my wall that I plan on incorporating into my design process.

This useful table can be found on page 30.

On page 30 there is a very useful table which lists all of the design patterns and talks about what aspect of your design each pattern lets you vary. I find this very useful early in the design process.

On page 24 there is a list of some common reasons you might redesign or refactor code. For each reason, it lists design patterns that address that issue. I find this quite useful for refactoring. In my refactoring presentation, I mention refactoring to a design pattern. This list helps me decide which design pattern I want to refactor to.

This is the start of a series of articles on Design Patterns. Her are the rest:

6 Comments on “Design Patterns – A review

    • That is a great reference Stefan, thanks for sharing. It does indeed look to be much easier reading than the GOF. Can’t wait to compare notes with you at GDevCon2.

  1. I’ve been on the fence as to whether to buy this for myself actually – thank you for the review, always interesting to have the opinion of a Software Engineer that uses LabVIEW. Cheers.

    • If you are thinking of buying this book you should also check out this ebook:

      https://refactoring.guru/design-patterns/book

      It is on sale right now. It’s pretty much the same content (same patterns and all) but its a little more approachable. The original book is very Computer Sciency. This newer book is more approachable. I like its examples a little better too. It also comes with a bunch of sample code in a variety of languages – but not LabVIEW.

      You can’t go wrong with either one though.

Leave a Reply

Your email address will not be published. Required fields are marked *

*