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

Since the author didnt mention it...

[josh crawley]

Is this book worthy of my money or is it antiquated piece of shit? The author of this review didn't include any sort of this question.

I have only limited funds, and I cant afford something that wont help me. So... all those who bought it, is it WORTH IT?

Thanks.

Re:Since the author didnt mention it...

[Vengeance]

Damn straight it's worth it.

As a developer, this book helps you to codify some concepts you've already got in your head, so you can latch onto them and understand them better. Patterns are applicable at every level, from little 20 and 50 line modules up to arbitrarily large systems. Get this book, or one based upon it that uses the language of your preference.

Re:Since the author didnt mention it...

[CowboyBob500]

antiquated piece of shit

The book is about design patterns. How can it be antiquated? Unless you're still programming in BASIC...

Bob

Nice to see /. as up to date as ever

[Anonymous Coward]

This book was published what, 8 years ago !

Nice to see /. at the leading edge as usual.

history lessons..

[TechnoVooDooDaddy]

hehe design patterns remind me of the quote "Those who do not learn from history are doomed to repeat it." or something like that...

if a problem has been solved, and well thought through, the pattern published and peer-reviewed, it probably will hold up for a good long while.

Re:history lessons..

[vrmlguy]

In other words...

while (!history.learn()) { snafu(); }

a great, but dangerous, idea

[ashultz]

This book is pretty great. It's also pretty dangerous, I've heard of idiots who rate the quality of any potential design by how many patterns it has in it.

Design patterns is important for every OO programmer to read, understand, and hopefully transcend.

Great book, goes well with ....

[goodviking]

This is a fantastic book. It is probably the best book out there for coverage of all of the fundamental design patterns. The examples are in Smalltalk and C++, and are readable and easily translatable to other OO langs (Java, C#, ...).

I would recommend that along with this book, you take a look at Pattern-Oriented System Architecture. It applies the design pattern concept to problems in large scale system architectures.

A combination of the techniques in both of these books can really help unwind alot of the spaghetti problems at both a system and component level. Additionally, alot of the fundamental concepts in modern system architectures become alot clearer once you've read both.

Re:Next Up in the Obvious Category...

[Dark Paladin]

Considering that the book uses pieces that are over 7 years old in a world where technology changes every few months, this review was useful to me - it told me that the information was still useful, valid, and actually might help my programming skills.

So no, I don't believe it was obvious at all - considering that I hadn't even heard of the book until today. (Yes, let the flames commence - I must be a bad, awful programmer because I haven't read some book.)

Overrated

[timeOday]

The book is worth looking at, but both it and design patterns as a whole are nothing much. It's hard to push through design patterns books, because most of the patterns will be familar to you already if you've done some design and/or used various frameworks and toolkits. The innovation of the design patterns book/movement is simply to give names to common design elements so they can be discussed. This is useful, but not a breakthrough of any sort.

Hell no

[PissingInTheWind]

[...] little changed from 1992! In the computer field this would be considered an ancient text with how fast software is updated and languages change.

Holy shit no. 1992 isn't 'ancient' in any way, only for people with very short memory and attention span. Or for people who thinks XML is a neat new idea. Or for people who thinks Java OO-model is a neat new idea. Or for people who thinks Patterns is the new silver bullet. Or for people who thinks Lisp is dead.

Hope you get the idea.

Re:Who Actually USES These Patterns?

[tequesta]

Banking and Scientific Computing are hardly leading innovators when it comes to software design (COBOL, anyone? FORTRAN, anyone?) But apart from that, it is my firm belief that any programmer worth her/his wages uses patterns. They may not be the actual patterns portrayed in the Gamma book, but they're patterns nonetheless.

The main good thing about this book is not that it lists a lot of patterns, but rather that it teaches you what a pattern is. This is truly a mind-altering experience. Once you grok the concept, you see patterns pop up all over your own code! Then you can extract and refine their specialties, encapsulate them and re-use them again and again.

This, besides saving you a shitload of future work, teaches you entirely new ways of thinking about object-oriented programming. I've talked to a lot of people who found that reading this book is truly a mind-blowing experience in that respect. Certainly changed my coding.

And the specific patterns in the book are kind of cool, too.

Re:Only shit coders read books like this

[Anonymous Coward]

uh, no. Authors of C++ device drivers are not the only "real" coders. I've risen far up the ranks in my career writing database apps with quality, intuitive front ends. My apps are well-designed, have few bugs, and solve numerous tasks that could not have been solved before I wrote them. The end users love me, and I'm well-compensated for what I do. I currently could not (nor wish to) write a low-level C++ device driver. Bleah.

Anyway, if you've got to write a low-level device driver, why are you using C++ at all? Get down to assembly level and do it right!

There are different types of problems out there that need solving. This book addresses ways of solving many of them.

Re:read the first chapter at the book store.

[Anonymous Coward]

I don't, I want software that runs and does something real. documents don't do anything but appease managers who can't code anyway. If you need to document your stuff use header files.

You sir, should be beaten soundly with a nice big thick document. As a sysadmin I cannot recall how many times I've run across mindless fecal matter such as yourself. Documentation is a key element in any piece of software, be it a shell script or a complex application. It gives maintainers something to look at to get up to speed and provides everyone who uses your software a reference from where they can start.

If you want to be an elitist prick who sits in a cubicle all day and writes code. Fine. Just remember that nobody in your office actually likes you and they all talk about what a prick you are behind your back. After a few years you will wonder why people who are your junior are now managing you. Keep pondering that and eventually you might become enlightened.

Good day.

Re:read the first chapter at the book store.

[fitten]

I wish you would have signed this so I would know to never hire you.

Something that you are most likely too young and inexperienced to understand yet is that you do not write code for yourself to maintain. A coder typically writes code and others will maintain it (because you left for another job, got promoted, the project was handed off to a maintenance crew, you got fired for your crappy work, or whatever). THEY have to make sense of your code to fix/maintain it.

If your code is cryptic and/or undocumented, it will cost your company/team lots of time (and time is money) and frustration to debug and/or modify it. Even if you are still in the group, someone else may need to go into the code that you wrote (notice that I did not say "your code" as it is not your code if you are working for a company or contributing to an open software project) to do something. If you routinely contribute such crap to open source projects, you will quickly be denied access to any further projects.

Re:Beware of overusing patterns.

[Anonymous Coward]

Two books spring to mind: "Antipatterns" and "Refactoring".

Antipatterns has a catalog of commonly occuring design mistakes and problems found in code. Like Lava Flow where layer upon layer of code has been squeezed into the same module Or God Class where one class controls and is coupled to everything else in the project. Bad programming practice can be classified just like good practicce.

Refactoring is all about how to fix design errors during coding. It places a strong emphasis on Unit Testing and is popular with the XP crowd. When faced with a problem in design during the implementation phase its never a good idea to kludge your way out of it. Use the controlled, testable processes described here to improve the design throughout the whole project.

None of these books should be restricted to the "planning phase" of the project. Rather revisit your original ideas and assumptions as your project progresses. If you find you've taken a wrong turn don't kludge it into an Antipattern, rather Refactor it into a better solution, using your suites of unit tests to ensure backward compatiblity with what you have already done.

Re:The Design Patterns Smalltalk Companion

[Anonymous Coward]

That's a good point. I strongly recommend reading the smalltalk companion, particularly if you're a C++-and-nothing-else coder.

However, I found that for multiple-dispatch OO languages like Common Lisp CLOS, both the Design Patterns book and the companion were somewhat less than useful (except for translating Java-weenie pattern-junkie-speak), since most of the patterns assume methods belong only to a single class - and some of them (In particular, THE DREADED VISITOR PATTERN) aren't really good patterns outside C++/Java, but actually represent workarounds for the limitations of single-dispatch OO.

Now, the authors were aware of this, and include it as a footnote to the visitor pattern. But on the whole, CLOS only gets three tiny mentions in the whole book, which is a shame, since multiple-dispatch OO is both more powerful and more natural, once you've UNLEARNED the classes-contain-methods rule. (multiple dispatch OO is akin to nouns+verbs in natural language, where hitting a nail with a hammer is different to hitting a schmuck with a lawsuit is different to hitting a schmuck with a hammer)

Decide for yourself...

[johnlcallaway]

Is it worth it?? Can't say, never read it. But,as an antiquated piece of shit myself that has seen every TNBT (the next big thing) come down the road, it probably was outdated 2 minutes after it hit the news stands, replaced by TNBT.

But, as an antiquated piece of shit who has bought dozens of other TNBT books, it might be worth it. We used to use things called algorithms, and had books written by the thousands with them. I still have a C book on my shelf at work that I reference from time to time because of code segments it has. A good book outlasts TNBT, since they basically all say the same crap. My test is to try and decide if it will make a good reference book, something that will be used every day and can make me an even better haxor than I are now (yes, I meant the poor grammer).

My advice is to get off your lazy geek butt and get thee to a real bookstore, not one of those Internet things. That you can do for free (well, I think you still can, there might be copyright issues). Pick it up and actually read portons of it. Buy it online if you can save a few bucks, or buy it right there if it is so good you can't live without it.

But, for geeks sake man (woman??), make up your own friggen' mind. Make a decision. Stand up for yourself. Don't follow the rest of TNBT sheep. Or go buy the damn thing because they said so, and continue to be an Windows NT programmer. (whoopss..did I say that??)

good to know about--but it's accepting defeat

[g4dget]

You should know about design patterns. They simply are a clear statement of object-oriented techniques that programmers have known about for decades. Think of it as a grammar and hanbook of style for programming languages.

But design patterns also show fundamental flaws in the object-oriented languages: design patterns are abstractions for which object oriented languages have no support. While object oriented languages have support for data structures and encapsulation in the form of type checking and access specifiers, when it comes to design patterns, you have to put them in by hand, document them by hand, and make sure they are working correctly by hand. Design patters are to object oriented languages like nested loops and data structures are to assembly language: you can implement them, but the language isn't going to help. The problem is that object-oriented languages really build abstractions out of individual classes and that individual classes are the units of abstraction and encapsulation, while design patterns require abstraction and type checking at the level of groups of classes. Attempts at supporting design patterns explicitly in object oriented languages so far also have been unsatisfactory as far as I'm concerned.

Re:Obligatory Anti-Pattern Viewpoint

[JeremyR]

Well, if I was ordered *not* to use a database else I would not get a paycheck, then you are right: GOF patterns may be better than the alternatives. But to me that is like saying, "Skateboards are better than walking if you are not allowed to use a car."

If you can't imagine any problem in computer science--particularly in the commercial application of computer science--that doesn't need to make use of a relational database, then either you are not trying, or you are experiencing acute myopia. As for the specific example of sorting, I'm sure you've seen some user interfaces that present some sort of data in tabular format. Often in such a UI, the user can click on a column heading to instantly sort the table according to the data in that column. It seems that your approach to implementing this feature would be for the client to request all the data from the database again, this time sorted by a different column. Wouldn't it be more reasonable just to re-sort the same data right in the client application?

I disagree. They tend to fight over territory. Procedural/relational techniques tends to abstract the noun modeling to the database, not programming code, which is where it is in most OO designs and GOF OO patterns.

Concepts don't fight over territory; people fight over territory. And I'll reiterate yet again: A design pattern is a solution to a problem. Design patterns are used a lot in OO, but they are by no means limited to OO. In fact they're not limited to software at all--design patterns originated with architecture and construction! So if patterns can be applied to building design and OO software design, is it that much of a stretch to say they can be applied to database design?

I would like to see them giving benefits above p/r in something I can relate to in actual code. Sorting, shapes, animals, device drivers, and the other common "training lore" used by OO enthusiasts do not appear to extrapolate to my domain. Whenever somebody has tried, the examples fall victim to my standard OO complaints about biz modeling and OO.

You want a nontrivial example? OK. Implement an instant messaging application (along the lines of AOL Instant Messenger), including both a server and two clients: a command-line and a GUI version. Clients and servers should communicate with each other using TCP/IP. Use only a relational database to implement the entire system.

(* Most (all?) of the pattern books assume that their audience is at least somewhat versed in the language of OO. You may not like OO, but it does provide a convenient language for the discussion of patterns. *)

Why is that? (Or, is that one of those questions that launches a thousand arguments?)

It's convenient for the authors to speak in the language of OO because their intended audience is fluent (or at least competent) in the language of OO. If you were to write a book about advanced optimization techniques for relational database applications, I would think your intended audience would have some sort of competency with relational database concepts.

Trolling earns +5 informative ?

[Martin S.]

the patterns found in the Gang of Four book for C++ and Java programmers mainly help losers lose less

Pandering to 'wannabie elite hackers' is now enough to earn +5 informative? Jesus!

If our Industry cannot develop the tools to move on from a hacking culture to a Proffessional Software Engineering culture, we may as well all give up and go and go back to living in mud huts.

The most simple fact is that Patterns (and the GOF) are to software engineering what Whitworth was to the Industrial Revoulution, the ubiquitous standard that make it possible for a spanner manufactured in Sheffield to tighten a bolt from Africa in a Bridge in Deli.

Try the following for a better insight into the importance of standards in creating a revolution.

http://www.ama-cycle.org/features/whitworth.asp
http://www.wired.com/wired/archive/10.01/standard s .html

---
It's not the ignorance in postings that disappoint it's the ignorant moderation.