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
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
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
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
- 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.
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:
