Design Patterns

BShive writes "Design Patterns is considered a classic for anyone in software development. The beginning third of the book is a solid introduction to patterns, while the last two thirds of the book is devoted to the patterns themselves. Many of the professionals out there probably already own a well-used copy of this book, but there are others who are wondering what all the fuss is about. The frequency of hearing about this text in discussions piqued my interest enough to buy it for myself. If you are interested in design patterns and are looking to use them, then this should be one of the books on your shelf." Read on for more. Design Patterns author Erich Gamma, et al pages 395 publisher Addison-Wesley rating 8 reviewer Ben Shive ISBN 0201633612 summary Design Patterns is considered a classic for anyone in software development. Many of the professionals out there probably already own a well-used copy of this book, but there are others who are wondering what all the fuss is about.

Introduction

I found the entire introductory section excellent, and a good read. It covers what design patterns are and explains how they are documented and categorized. Advice on where and how to employ design patterns to achieve reusable and flexible software is also covered to give you an expectation of what you can get out of the rest of the book. The What, Why, and How are covered nicely. Even with little previous exposure to patterns, I was able to understand the presented material easily and begin to see the applications.
Object Modeling Technique (OMT) notation is also introduced to explain the diagrams associated with the patterns and examples. If you have used UML, the diagrams and notations will be familiar to you since UML is influenced by OMT. Jim Rumbaugh, the creator of OMT, collaborated with Grady Booch to create the first version of UML.

As the author notes, having a solid knowledge of OOP is critical to being able to understand and use the information presented. If you don't fully understand OOP, pick up an introductory text first. An Introduction to Object-Oriented Programming by Timothy A. Budd or any similar book will get you up to speed. However, you will get the most out of Design Patterns with hands-on OOP experience.

Case Study

This chapter presents a case study in designing a WYSIWYG document editor to demonstrate how design patterns can be applied. Most of the examples in the book involve the user interface and I would have liked to see less emphasis on UI models. However, it still gives the reader insight into real applications of patterns. Not only do the authors point out how the pattern applies to each case, but they also present the problems associated with the application. The case study is not intended to set up a perfect example of pattern usage, but to explore it. The reader could go further with the design presented and think about how to solve the flaws pointed out along with the ones that have not been discussed. I liked the fact that they do not attempt to state that there is only one way to solve the problems presented, or that their solutions are even the best way. Too many authors fall into this trap.

Presenting: The Patterns

The three chapters on patterns make up the bulk of the book. The patterns are separated out into the three chapters by type: Creational, Structural, and Behavioral. Each chapter begins with an overview of what the patterns of the type can be used for, and how the chapter deals with the patterns as a group. At the end of each chapter there is a discussion section that summarizes the patterns, along with guidance on how to select the right one from the chapter.

Each pattern description contains a number of sections: Intent, Also Known As, Motivation, Applicability, Structure (in OMT), Participants, Collaborations, Consequences, Implementation, Sample Code, Known Uses, and Related Patterns. The breakdown makes it easy to determine if, why, and how you should use the pattern. The authors are justifiably concerned about using the wrong pattern for a given situation. The code snippets are also easy to work through as long as you know an OOP language. C++ is commonly used, with the occasional bit of Smalltalk code.

The three chapters that detail each pattern would be difficult to read right through. However, the opening and closing section of each chapter has valuable information and is worth reading and subsequently referring to some of the patterns discussed. I got the most out of these chapters by picking patterns that might apply to current projects I was working with and then exploring one in depth, branching over into other patterns in a non-linear fashion.

Conclusion

The closing chapter is relatively short, but makes some important points. The authors discuss what to expect from design patterns, some history and other references/influences. Re-factoring is discussed and how patterns will help mitigate this unavoidable process as the software evolves. Other benefits are also brought up briefly. The book closes with an invitation to give the authors feedback and to find patterns that you use. The best designs will use many design patterns that dovetail and intertwine to produce a greater whole.

Book Extras

The whole book has a quality feel to it that is missing from many current texts that cost nearly twice as much. Inside the front cover there is a quick reference to all of the patterns contained in the book with a brief description and page number. The back cover also contains a quick reference for diagram notation and the relationships between the design patters. This is all topped off by two bookmark ribbons attached to the spine.

The Age Issue

Design Patterns was originally published in 1995, and the book mentions that the patterns it contains are little changed from 1992! In the computer field this would be considered an ancient text with how fast software is updated and languages change. Despite this, since the material is not entirely dependent on a particular language or program it holds up quite well. The examples referred to for each pattern are older software that many will not recognize. An updated version would be nice, but being old does not condemn this book to being useless.

Summary

This is an excellent book even if it is beginning to show its age. The fact that it's still very useful is testimony to the quality of the material. A few readers might find the reading to be a bit dry, but the straightforward style was refreshing compared to some other texts. The authors stay focused on the topic and condense it appropriately without going off onto long tangents. Once I've followed through with applying some patterns to projects it might garner an even higher rating. Just from reading about some of the patterns, I could see how they could have applied to previous projects I've worked on, both large and small. The book was certainly a worthwhile investment. If a second version of this book ever comes out, I'd be sure to pick it up as well.

Chapters:
1. Introduction
2. A Case Study: Designing a Document Editor
3. Creational Patterns
4. Structural Patterns
5. Behavioral Patterns
6. Conclusion

Appendix:
A. Glossary
B. Guide to Notation
C. Foundation Classes

You can purchase Design Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Only shit coders read books like this

[Viol8]

The sort of people who read these books are the sort who normally couldn't code their way out of a paper bag. Ask them to write a low level device driver or network protocol and they'll piss their pants , but ask them to write some high level description of some GUI front end using as many buzzwords as they can shoehorn into the design document and they're in their element. And this is one of the books they'd have sitting on their shelf. Its a comfort blanket for people who kid themselves they're programmers but in reality are designers who should never be let near any C++ compiler. Is it any wonder with modern day management trumpeting this kind of rubbish that afar greater percentage of IT projects overrun, are overbudget and don't meet the spec than ever before?

What exactly is a "pattern"? Need good def

[Tablizer]

pointing out that they've had their own "patterns" all along: they're called "algorithms".

This harks again to a question of definitions. What is the difference between:

1. Patterns
2. Algorithms
3. Formulas

Different design methodologies and languages will implement that same thing with different arrangments of these three. (FP and relational will tend to use formula-like thingies instead of class-like structures to represent the GOF patterns, for example.)

It might help clear up some hype and flame-wars if there were agreed-upon definitions of each of these.

Re:Moderators - YHBT. HAND.

[Tablizer]

His intellectual hostility towards anything except his own ideas (and object oriented programming in particular) is fairly well known,

Intellectual honestly? All OO fans do is appeal to authority, usually their own, almost NEVER objective code or facts. Glass houses.

In short, this is a fellow who has ver likely never really bothered to try to understand design patterns, nor any other OOP concept,

Odd, I feel that OO fans don't bother to understand databases and relational thinking, using it as a mere "storage mechanism" and can't see beyond that.

For more details, feel free to try and twist your brain around his article on Table Oriented Programming

I suggest you start here instead:

http://geocities.com/tablizer/whypr.htm

The page you reference admittedly needs some "refactoring". It is not my most consice work (probably why you selected it as a "representative" wipping boy).

Carl Sagan's quote about genius...

Carl Sagan also said that science should not be based on authority, but open observable information and analysis.

This is something that OO fans don't like because their entire claim set depends on nothing externally observable except fan opinions.

Yes, my opinions are controversial and perhaps against the prevailing wisdom. However, they are backed by at least as much information and evidence as OO relies on.

If you have grand open evidence that OO is objectively better than database-centric approaches, then please present it. I love good evidence, especially when there is a drought of it. Fix your evidence instead of attacking me personally.

A. Stepanov and Paul Graham, both very successful people, have also said unpleasent things about OO and/or OO patterns. Where is your attack of them? Why attack me? I am a no-name.