I thinks this is a great book for anyone wanting to learn or have a reference on design patterns. It does expect the user to know OO C++. It is definetly a book for software engineers to have on their collection.

The concept of design patterns transcends programming languages. If you wish to think "outside the box" yet be effective and efficient, either this book will provide the answer or help you think in ways that you can develop our own design. A must read.

I would say this book was a bit old school in it's approach and content, but was exactly what i needed to get a good starting point in understanding how to use design patterns in my software designs. The case studies it presented were simple problems but contained practical elements I could apply to my next big project.

This is the most recommended book on object oriented design. I can see now.what all the hype is about. I have been a developer for almost six years now. I have been using object oriented languages for some time. Despite the experience with the technologies, I didn't have a good working knowlege of how to effectively implement the technology and methodology in my own code. That is, until I read "Design Patterns". It has opened my eyes and I understand the concepts of polymorphism and code reuse much more clearly now.

"Design Patterns" is easy to read, easy to understand and has great code examples that facilitate understanding. It is my opinion that if you haven't read this book and you develop with OOP, you are probably working harder and not smarter. So do yourself a favor and pick up a copy.

I give this book a 3 because it was great when it was written. But now, it is not a very good book to read. Most people who read it acknowledge they can't understand it. There are two excellent books on the market that should be read if you want to learn design patterns.

Head First Design Patterns (Head First) - is the best book to read on what patterns are as solutions to a problem in a context. Fun to read, useful, really wonderful *****.

However, if you want to learn what patterns really are - the thought process behind them, read Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition) (Software Patterns Series) *****

A related book that would also be a good read is Scott Bain's Emergent Design: The Evolutionary Nature of Professional Software Development (Net Objectives Product Development Series) *****

Let's give tribute to the acknowledged #1 classic in the modern software industry. But it is not the book to read to learn patterns anymore.

This book is a classic and doesn't require any further presentations. It is THE Design Patterns bible and every OO programmer should read at least a couple of times.

The samples are in C++ and sometimes Smalltalk but that really doesn't change anything even if you are a Java or C# guy.

If you are looking for a quick way into patterns I'd recommend Head First: Design Patterns as your 1st reading, but buy both and get ready to start reading this one right after.

Overall a good book. In my opinion it is better suited to be a textbook for a software engineering course than a 'self help' kind of book. Can be a bit too theoretical for my taste, but it is an interesting read.

This book doesn't contain any Java hacks or UML 2.0 up to date notations, it contains the core concepts of software design patterns. The 23 GoF Patterns are described by their four inventors. A must have for software engineers.

unlike the last pattern book i reviewed (see my other reviews), this one has an attractive cover. i like blue.

Most of the books I have read about object oriented programming were about some specific language and failed to provide a more general way to think about solving problems without writing a lot of code. This book was a missing link for me and I wish I had read it sooner. The authors provide you with elegant ways to use object oriented language features to simplify your programming solutions.

When the specs on your project change and you have to re-factor your code, you may be able to use a design pattern from this book to simplify your solution and make your design more flexible with regard to the parts of the spec that are changing quickly.

This is a great book on design patterns. Not only does it cover the theory of what each pattern is and it's respective use. It also gives very concrete examples of the proper use of each pattern in C++. I highly reccomend this to any serious programmer.

Contents of Disign Patterns are more and more classical in software engineering. The work is unaguable the basis which lead to a growth of design patterns. This particular issue is a high-quaulity hardcover on heavy paper, and good print. Its an issue for all who like to have a personal library of important book in superior quality. Well useful are the two bookmarks available in the robust binding.

I got this book expecting there to be some new and interesting material inside, however I was sadly mistaken on that count. This is a repackaging of some pretty standard concepts, into new wordier jargon. Introducing new jargon for existing jargon does nothing but complicate the situation! There are something on the order of 30 design patterns introduced all but 5 or 6 of these are pretty useless. If you're a software engineer working with c++, there's nothing in here you haven't seen before.

Being a total noob to programming, my friend got me into learning about Objective-C and Cocoa. I have bought many books on the subject and I'd like to say that this book helped me with my understanding of objective-c programming language.

Thanks to the authors

The book is wonderful and samples are very exciting and meaningful.But book is difficult,if you don't have any idea about design patterns,you cannot learn easily from his book.But If you are not new about Design patterns,this book is very useful.

I would recommend this book to any software developer, architect, or designer. Fit for all levels of experience. It is clear why this is so often referenced in other development literature.

I have read this book many times over. I purchased
this book many years ago and I still reference it today. For those
who are interested in OO design this is the best book I have read,
followed by John Lakos "Large Scale C++ Design". This book will
have you thinking about how to design software, and if you are
diligent, eventually you will be designing your own patterns.

This book is a definite must for any language, since it will
change the way you view software.

I found the case study very helpfull. The patterns explained in a very clean way, so I recomand every developer that is interesting in design patterns, refactoring etc to read it.

This fascinating and extraordinarily clear text guides you in such a persuasive way through the world of software design patterns that once you start reading it you won't want to stop until it is over.

I don't have much formal programming training... much of what I've learned has been through self study. As a consequence, many times I'm not sure if I know something or not. Usually, I try to convince myself I know something but a tiny bit of doubt remains in the back of my head. This is the case for me with respect to object oriented programming. I thought I understood what object oriented programming was about, but I would only use it for certain parts of my programs (using perl, where things are not necessarily object oriented). Also, I would have trouble understanding large OO'd software packages. Reading this book really caused things to click in my mind and I realized what exactly object oriented was all about, how to use object orientation, how not to use it, etc.

Some of those who gave this book low ratings might reasons from their situation, but for me this book helped a lot. I'll agree that the concepts are abstract and difficult, but the authors set up different paths thru the book depending on the readers goals. I think a beginning programmer would get blown away by this book, while experts might know it all from good teachers or painful experience. For me however, this book gave me a bunch of "aha!" moments as the authors explain situations that make programming tricky and explain the solutions.

Also, the book is nice and solid w/ two bookmark ribbons (at least for the hardcover version). Very high quality and not so expensive compared to college textbooks.

Excellent explaining about the design patters even for those who are new to it.
The only problem is that the samples are in C++ wich should be expected because the book was printed in 1995.

10 years ago this book revolutionize the way programmers see object oriented programming. At that time, it was essential to read it. In fact, I remember that employers were testing candidate knowledge on design patterns at job interviews. Today, I consider this book as a classic that I would recommand to read for everyone that has just learned object oriented programming but it is less essential than it used to be as design patterns knowledge has spread in the litterature and you could even learn about them just by working on existing code. That being said, this book is still very valuable even for people that already know about patterns. I am on my second reading after many years of using the design patterns and I am picking up new insights that has escaped my attention at the first reading.

clearly defines design patterns, how and when they should be used, and factors to consider when using them. a very useful book for any software development work. the only disadvantage with this book is that its examples of each design pattern are sometimes convoluted and confusing.

Not even having cracked into the actual patterns yet, this book has already helped me in the way I think about object-oriented design.

As I read I keep thinking back to past projects and thinking about the techniques being described and how much they would've helped me at the time.

Buy it now, don't hesitate.

If you are a software developer, buy this book, period. It is expected that any professional developer has read this book front-to-back!

I think every Solution Architect or Software Engineer must have this book. It's the start of all.

This book is overrated, but it does have utility in bringing to your attention design patterns --which should be obvious to any good programmer--such as the Singleton (object only capable of instantiation once).

Why do I say obvious? Because any programmer worth their salt will over time develop their own home-grown library of patterns and exemplars to reuse. This book merely calls attention to this habit.

Also, as other reviewers have pointed out, the text is too generic and abstract, unless you're into that. Donald Knuth anybody?

Plus the book is too expensive--if you must, buy it used like I plan to. That's right, I haven't read it yet. But I know enough just reading these reviews; sometimes you CAN judge a book by the cover. I am over the age of 13, yes.

Of all the programming books that I've ever read, this one has had the most impact on my programming. I require that all programmers who work for me read Design Patterns.

Of all the programming books that I've ever read, this one has had the most impact on my programming. I require that all programmers who work for me read Design Patterns.

Muy bueno, muy claro y tiene buenos ejemplos que permiten asimilar los conceptos y llevarlos a la práctica

Really makes clarity on OO programming patterns giving a complete overview and nice examples. Uses UML to describe pattern classes, sequence diagrams and collaborations. Maybe sometimes it's not so concrete in examples and keeps itself too generic.

It's a classic and a must have for the OO developer.

Good basic reference book for design patterns. The organization is NOT for reading ease, but for easy reference when you know what you're looking for to be reminded exactly what a particular pattern is all about. One sentence synopsis--Encapsulate what you expect to change.

This book does a great job of explaining patterns and pointing out benefits and drawbacks to each one. As an aspiring OO developer of business applications though, this books does not provide much guidance. The examples are given for real-time applications like user interfaces for a drawing application, etc. Applying these patterns to a distributed application with a database backend that records everything is a tough leap to make. I give it a high rating because it does its job well, however, I wish it would have addressed a broader scope of application types.

Although this book initiated the now-famous design patterns phenemon,I think we have better alternatives these days.The book has sample codes in C++.

I personally liked Head First Design Patterns.

Everyone who wants to write OO code needs to read this book. No, let me re-phrase, *must master* this book.

When you have *mastered* this book, we will award you a blue belt and you can then move on to Martin Fowler's book.

If you don't know which book I mean by "Martin Fowlers" book, you haven't mastered this book. So don't expect the blue belt until you do.

Expect only beatings with the blue belt.

"Design Patterns" (GoF = Gang of Four) is a signicant and, in many ways, a difficult work for the modern reader (me) to digest. The material in this book is highly self-referential: to understand a particular design pattern, it is important to be familiar with many similar, if not all, design patterns.

I would like to offer a suggestion about an approach that worked well for me. As an introduction to the patterns field, I first read "Head First Design Patterns", which offers a highly competent but light-hearted presentation of the same patterns covered by GoF. The Head First book gave me a thorough overview of the patterns landscape, as well as gently drilling me on pattern application. The Head First book goes out of its way to provoke the thinking reader, while being the most entertaining computer science text that I have ever read.

With this introduction, I found "Design Patterns" to be a much more accessible and friendlier work.

You've got to read it, if only to say you read it :-) True, the book is C++ focused (it will be somewhat tough for those who only know Java / C#) and it has quite a level of sophistication (probably aimed at those in a Computer Science degree or master's programs). But, that said, it really started a big part of the revolution in OO - open source gave us reusable code, design patterns gave us reusable solutions to design problems; and this was the book that really "lit the fire" for patterns.

It is a good direction for the Software Engineers to learn about patterns and designing the applications.

This is my primary resource for reference purposes. It's my first stop when I need a specific pattern. I recommend the Head First book for learning; this book for the basic patterns; and Martin Fowler's Enterprise Application Architecture book if you are designing business applications. Also, Partha Kuchana's Design Patterns in Java book is great if you are using Java.

This is the best design patterns book ever
language is simple.
examples are usefull
this is a must-have book

Design Patterns is an essential book for every software developer or architect. It was ground breaking for it's time, describing reusable design patterns that recur in software development projects.

The presentation used makes reading and understanding the concepts easy, and allows one to learn and apply the patterns a few at a time. It's a great reference book, and the distilling and naming of the patterns really aids communication between developers.

There are few books in the software industry that hold up for any length of time. This is one of the exceptions. In my work, I refer to this book periodically and find that it offers more over time. This book should be on the shelf of most object oriented programmers.

Object orientation is about dynamic binding, encapsulation, inheritance, and polymorphism. It's not necessarily about 20 patterns and their permutations. If you understand the basics, then you're set. But unless you're in an environment like Smalltalk where you can see OO unadulterated, then GoF is the next best thing.

The authors carefully format their presentation, and cross reference patterns for completeness. They review double dispatching (callbacks), pluggable adapters, lazy initialization, factories, deep vs shallow copying, and delve into detail, showing how misapplications can lead to unintended consequences.

GoF emphasizes early on that inheritance is overused. There are too many deep, inflexible layers of inheritance out there, a habit GoF helps snap.

Sometimes though, they lose the forest in the trees. Key ideas get lost in sub-topics, and while it took me awhile to be convinced that some patterns had a unifying idea, others are redundant.

For example, a Strategy is similar enough to a State pattern, since both extend functionality conditionally through collaboration rather than inheritance, and both will likely involve callbacks and fit the Visitor pattern as well. And instead of the Adapter, Mediator, and Observer patterns, I would have preferred a generalized discussion on event dependency and pluggable adapters with specific examples in increasing complexity and differentiation.

But there's an allure to the idea of 'patterns', and it helps sell components. 'Polymorphism' and 'Smalltalk': bad marketing. They sound like diseases and phobias. The names were fine in the early 90s, but now they are marketing to a wider audience upon whom those fine points will be lost. 'Patterns' and 'Java': good marketing.

Gang of Four is a book about which I have mixed feelings, both in terms of its inherit merits, as well as of its repercussions, but there's no doubt about its heralded place among A&D books. This is a review not only of GoF, but of the environment into which it was received.

In 1995, when this book was released, you could find infrastuctures using pure OO, but they tended to be specific companies which had unique requirements for 'distributed' applications running concurrently on multiple operating systems. In an era of Microsoft and Netware (versus the mainframe), before the web, this was highly uncommon. Smalltalk was often the language of choice for distributed OO, with Gemstone as the OO database-app server.

People doing OO and Smalltalk were going against the grain, against every single mainstream software company. But they did it cause they knew that OO was the right paradigm for multi-platform applications.

I remember building a mail system which ran objects from a mainframe over a home-made orb to mirrored object database-app servers, over a wireless network onto hand-held devices running footprint OO systems - 4 or 5 tier depending on how you count, in 1995, when most apps were 2 tiers over a LAN. Everyone involved had a maverick spirit, unless they just happened to fall in. CORBA was coming together and things pointed towards a rosy future for OO.

But some bridges had to be crossed. One was involving programmers from other languages. Another was getting virtual machines into web browsers. Sun Microsystems decided to trade its reputation in the Unix server market for a chance to bump off Microsoft in the end user market, envisioning a world of networked applications. Initially, they had wanted to license Visual Works Smalltalk from ParcPlace, but were unable to reach agreement.

Sun decided to retrofit a language called Oak that they had been working on in-house for distributed set-top boxes. They basically wanted to build a Smalltalk with C++ syntax and fixed data typing, with protocols for the web.

There were enough people drawn to Java by its emphasis on web distribution, rather than OO, that the language began introducing artifacts from procedural code, as evident in EJB, inner classes, a compromised MVC model for Swing, and unenforced encapsulation.

The real fallout was when new Java developers began writing code and it wasn't OO at all. I remember one Wall Street project where the application consisted of one big class encapsulating lots of nested inner classes. This was architected by a premiere Java shop in Manhattan.

GoF helps people discover and articulate object patterns in a language-independent way, within the confines of static data typing, with demonstrations in C++ . It's too bad the book was written only one year before Java's release, or they would have provided examples in Java as well, but the C++ syntax maps well enough.

The best way to learn OO is first hand, by downloading a free version of Smalltalk and experimenting. OO is about dynamic binding, encapsulation, inheritance, and polymorphism. It's not necessarily about 20 patterns and their permutations. If you understand the basics, then you're set. However, for most people, the idea of taking on another language is a headache in itself. GoF takes the time to show examples of Smalltalk code and concepts, and how to translate those ideas into C++.

The authors carefully formatted their presentation, and cross referenced patterns for the sake of completeness. They review important concepts like double dispatching, pluggable adapters, lazy initialization, factories, deep vs shallow copying, and delve into detail, showing how misapplications can lead to unintended consequences.

GoF emphasizes early on that inheritance is overused. Too many times I've seen deep, inflexible, hierarchical layers of inheritance. GoF spends most of its time showing how to break that predilection.

Sometimes though, I find that they lose the forest in the trees. Key ideas got lost in sub-topics, and while it took me awhile to be convinced that some patterns had a unifying idea, others were obvious, and still others redundant.

For example, a Strategy is similar enough to a State pattern, since both extend functionality conditionally through collaboration rather than inheritance, and both will likely involve double dispatching and fit the Visitor pattern as well.

Another example is how the pluggable adaptor/event architectures are spread across the Adapter, Mediator, Observer patterns. I would have preferred a generalized discussion on the basic techniques of event dependency and pluggable adapters with specific examples in increasing complexity, and encourage architects to select functionality from there as they wish.

But I think there's an allure to the idea of 'patterns', rather than 'techniques', because it helps sell the idea of components.

And OO needs good marketing. 'Polymorphism' and 'Smalltalk': bad marketing. They sound like diseases and phobias. 'Patterns' and 'Java': good marketing.

A final note about the proliferation of OO to other languages: With Java and C++, OO programmers can move out of Smalltalk's GUI IDEs, onto the command line, and into Linux, GNU, vi, CVS, crontab, accept, tripwire, ssh, and a host of other utilities, shells and languages. GoF played a role in that evolution.

Gang of Four is a book about which I have mixed feelings, both in terms of its inherit merits, as well as of its repercussions, but there's no doubt about its heralded place among A&D books. This is a review not only of GoF, but of the environment into which it was received. I don't think my review will be popular with the far more numerous C++ and Java programmers who were introduced to OO A&D by GoF, but so be it.

In 1995, when this book was released, you could find infrastuctures using pure OO, but they tended to be specific companies which had unique requirements for 'distributed' applications running concurrently on multiple operating systems. In an era of Microsoft and Netware (versus the mainframe), before the web, this was highly uncommon. Smalltalk was often the language of choice for distributed OO, with Gemstone as the OO database-app server. People doing OO and Smalltalk were going against the grain, against every single mainstream software company. But they did it cause they knew that OO was the right paradigm for multi-platform applications.

It was an exciting time. A lot of ideas which are now standard were first being conceived, sometimes in front of your eyes. I remember building a mail system which ran objects from a mainframe over a home-made orb to mirrored object database-app servers, over a wireless network onto hand-held devices running footprint OO systems - 4 or 5 tier depending on how you count, in 1995, when most apps were 2 tiers over a LAN. Everyone involved had a maverick spirit, unless they just happened to fall into it. CORBA was coming together and things pointed towards a rosy future for OO.

But in order to spread OO beyond its community, some bridges had to be crossed, and one was involving programmers from other languages. Another bridge was the emerging web. Sun Microsystems decided to trade its reputation in the Unix server market for a chance to bump off Microsoft in the end user market, envisioning a world of distributed network applications. Initially, they had wanted to license Visual Works Smalltalk from ParcPlace, but were unable to reach agreement.

Sun decided to retrofit a language called Oak that they had been working on in-house for distributed set-top boxes. They basically wanted to build a Smalltalk with C++ syntax and fixed data typing, with protocols for the web.

There were enough people drawn to Java by its emphasis on web distribution, rather than OO, that the language began introducing artifacts from procedural code, as evident in EJB, inner classes, a compromised MVC model for Swing, and unenforced encapsulation. The real fallout was when new Java developers began writing code and it wasn't OO at all. I remember one Wall Street project where the application consisted of one big class encapsulating lots of nested inner classes. This was architected by a premiere Java shop in Manhattan. I think they thought it was nifty.

The general drift was the people running the Java shops were coming from Unix/C++ and didn't care much about OO. They would talk about Java as a brand new world, throw in the OO tagline, but they really didn't want to invest in A&D re-training. They seemed more intrigued by the clever non-OO workarounds which Java afforded.

So, into that void steps this book, GoF. It actually had come out a couple years earlier, intended as assistance to C++ programmers, but the upcoming generation of Java students were going to be a bigger market.

GoF helps people discover and articulate object patterns in a language-independent way. It also helps people implement OO within the confines of static data typing. The authors spent a lot of time on format and presentation, and cross referenced their patterns for the sake of completeness.

OO is about dynamic binding, encapsulation, inheritance, and polymorphism. It's not necessarily about 20 patterns and their permutations. If you understand the basics, then you're set.

Unfortunately though, C++ and Java are such that they don't always reflect OO architectural concepts. Therefore, this book is a helpful guide for writing code (in C++ at least) which approximates. It's too bad the book was written only one year before Java's release, or they would have provided examples in Java as well, but the C++ syntax maps well to Java.

The best way to learn OO is first hand, by downloading a free version of Smalltalk, observing and experimenting. I firmly believe that, but I acknowledge that for many people it would seem like an unnecessary diversion in their busy lives.

A fine point that GoF raises is that inheritance is over-used. Too many times I've seen deep, inflexible, hierarchical levels of inheritance. I prefer to see if there is some other way of associating objects, such as delegation, as demonstrated by the Decorator and Bridge examples. After all, inheritance can be perceived as a violation of encapsulation.

There are important ideas expressed in this book, such as double dispatching, pluggable adapters, lazy initialization, factories, deep vs shallow copying, etc. GoF does a good job of delving into considerable detail, enough to show how misapplications can lead to specific unintended consequences. Very good analysis of these architectures.

Sometimes though, I find that they lose the forest in the trees. Key ideas get buried more than once. In fairness, that's because they're trying to use one pattern to describe varying criteria over several languages. But there were some patterns that took me awhile to be convinced of the unifying idea, such as Factory Method. It's only in the final two sections that I realize they're talking about having a class/static method for returning a specific subclass.

Also, I find that some patterns are redundant enough not to warrant differentiation. For example, a Strategy is similar enough to a State pattern, since both extend functionality conditionally through collaboration rather than inheritance, and both will likely involve double dispatching and fit the Visitor pattern as well. I think they could have talked about inheritance versus delegation, with specific examples including dispatching, and be done with it.

Another example is how the pluggable adaptor/event architectures are spread across the Adapter, Mediator, Observer patterns. I would have preferred a generalized discussion on the basic techniques of event dependency and pluggable adaptors with specific examples in increasing complexity, and encourage people to mix and match functionality from there as they wish.

But I think there's an allure to the idea of 'patterns', rather than 'techniques', because it helps sell the idea of components.

And OO needs good marketing. 'Polymorphism' and 'Smalltalk': bad marketing. They sound like diseases and phobias. 'Patterns' and 'Java': good marketing.

A final note about the proliferation of OO to other languages: With Java and C++, OO programmers can move out of Smalltalk's GUI IDEs, onto the command line, and into Linux, GNU, vi, CVS, crontab, accept, tripwire, ssh, and a host of other utilities, shells and languages. OO needed to move beyond Smalltalk, to leverage these other technologies, and GoF played a role in that evolution.

Gang of Four is a book about which I have mixed feelings, both in terms of its inherit merits, as well as of its repercussions, but there's no doubt about its heralded place among A&D books. This is a review not only of GoF, but of the environment into which it was received. I don't think my review will be popular with the far more numerous C++ and Java programmers who were introduced to OO A&D by GoF, but so be it.

In 1995, when this book was released, you could find infrastuctures using pure OO, but they tended to be specific companies which had unique requirements for distributed, interactive applications running concurrently on multiple operating systems. In an era of Microsoft and Netware (versus the mainframe), before the web, this was highly uncommon. Smalltalk was often the language of choice for distributed OO, with Gemstone as the OO database-app server. People doing OO and Smalltalk were going against the grain, against every single mainstream software company. But they did it cause they knew that OO was the right paradigm for multi-platform applications.

It was an exciting time. A lot of ideas which are now standard were first being conceived, sometimes in front of your eyes. I remember building a mail system which ran objects from a mainframe over a home-made orb to mirrored object database-app servers, over a wireless network onto hand-held devices running footprint OO systems - 4 or 5 tier depending on how you count, in 1995, when most apps were 2 tiers over a LAN. Everyone involved had a maverick spirit, unless they just happened to fall into it. CORBA was coming together and things pointed towards a rosy future for OO.

But in order to spread OO beyond its community, some bridges had to be crossed, and one was involving programmers from other languages. Another bridge was the emerging web. Sun Microsystems decided to trade its reputation in the Unix server market for a chance to bump off Microsoft in the end user market, envisioning a world of distributed network applications. Initially, they had wanted to license Visual Works Smalltalk from ParcPlace, but were unable to reach agreement.

Sun decided to retrofit a language called Oak that they had been working on in-house for distributed set-top boxes. They basically wanted to build a Smalltalk with C++ syntax and fixed data typing, with protocols for the web.

There were enough people drawn to Java by its emphasis on web distribution, rather than OO, that the language began introducing artifacts from procedural code, as evident in EJB, inner classes, a compromised MVC model for Swing, and unenforced encapsulation. The real fallout was when new Java developers began writing code and it wasn't OO at all. I remember one Wall Street project where the application consisted of one big class encapsulating lots of nested inner classes. This was architected by a premiere Java shop in Manhattan too,

The general drift was the people running the Java shops were coming from Unix/C++ and didn't care much about OO. They would talk about Java as a brand new world, throw in the OO tagline, but they really didn't want to invest in A&D re-training. They seemed more intrigued by the clever non-OO workarounds which Java afforded.

So, into that void steps this book, GoF. It actually had come out a couple years earlier, intended as assistance to C++ programmers, but the upcoming generation of Java students were going to be a bigger market.

GoF helps people discover and articulate object patterns in a language-independent way. It also helps people implement OO within the confines of static data typing. The authors spent a lot of time on format and presentation, and cross referencing their patterns for the sake of completeness.

OO is about dynamic binding, encapsulation, inheritance, and polymorphism. It's not necessarily about 20 patterns and their permutations. If you understand the basics, then you're set.

Unfortunately though, C++ and Java are such that they don't always absorb OO architectural concepts effortlessly. Therefore, this book is a helpful guide for writing code (in C++ at least) which approximates. It's too bad the book was written only one year before Java's release, or they would have provided examples in Java as well, but the C++ syntax maps well to Java.

The best way to learn OO is first hand, by downloading a free version of Smalltalk, observing and experimenting. I firmly believe that, but I acknowledge that for many people it would seem like an unnecessary diversion in their busy lives.

A fine point that GoF raises is that inheritance is over-used. Too many times I've seen deep, inflexible, hierarchical levels of inheritance. I prefer to see if there is some other way of associating objects, such as delegation, as demonstrated by the Decorator and Bridge examples. After all, inheritance can be perceived as a violation of encapsulation.

There are important ideas expressed in this book, such as double dispatching, pluggable adapters, lazy initialization, factories, etc. GoF delves into considerable detail, not only describing how things work, but unintended consequences as well, which is super-thorough.

Sometimes though, I find that they lose the forest in the trees. Key ideas get buried more than once. They never seem to find a consistent way of presenting a pattern's defining characteristics. Despite the apparent order, I find slight chaos in the exposition. Perhaps their perspective is just different from mine, and reconciling the two takes inordinate time. Perhaps OO patterns defy such rigorous categorization and dilineation, like sand slipping through your hands.

One final note about the proliferation of OO to other languages: With Java and C++, OO programmers can move out of Smalltalk's GUI IDEs, onto the command line and text files, and into Linux, GNU, vi, CVS, crontab, accept, tripwire, ssh, and a host of other utilities, shells and languages. OO needed to move beyond Smalltalk, to leverage these other technologies, and GoF played a role in that evolution.

Gang of Four is a book about which I have mixed feelings, both in terms of its inherit merits, as well as of its repercussions, but there's no doubt about its heralded place among A&D books. This is a review not only of GoF, but of the environment into which it was received. I don't think my review will be popular with the far more numerous C++ and Java programmers who were introduced to OO A&D by GoF, but so be it. If I wanted to be popular, I wouldn't have gotten into OO to begin with.

In 1995, when this book was released, you could find infrastuctures using pure OO, but they tended to be specific companies which had unique requirements for distributed, interactive applications running concurrently on multiple operating systems. In an era of Microsoft and Netware, before the web, this was highly uncommon. Smalltalk was often the language of choice for distributed OO, with Gemstone as the OO database-app server. People doing OO and Smalltalk were going against the grain, against every single mainstream software company. But they did it cause they knew that OO was the right paradigm for multi-platform applications.

It was an exciting time. A lot of ideas which are now standard were first being conceived, sometimes in front of your eyes. CORBA was being standardized and things pointed towards a rosy future for OO.

But in order to spread OO beyond its community, some bridges had to be crossed, and one was involving programmers from other languages. Another bridge was the emerging web. Sun Microsystems decided to trade its reputation in the Unix server market for a chance to bump off Microsoft in the end user market, envisioning a world of distributed network applications. Initially, they had wanted to license Visual Works Smalltalk from ParcPlace, but were unable to reach agreement.

Sun decided to retrofit a language called Oak that they had been working on in-house for distributed set-top boxes. They basically wanted to build a Smalltalk with C++ syntax and fixed data typing, with protocols for the web.

There were enough people drawn to Java by its emphasis on web distribution, rather than OO, that the language began introducing artifacts from procedural code, as evident in EJB, inner classes, a compromised MVC model for Swing, and unenforced encapsulation. The real fallout was when new Java developers began writing code and it wasn't OO at all. I remember one Wall Street project where the application consisted of one big class encapsulating lots of nested inner classes. This was architected by the premiere Java shop in Manhattan too.

The general drift was the people running the Java shops were coming from Unix/C++ and didn't care much about OO. They would talk about Java as a brand new world, throw in the OO tagline, but they really didn't want to invest in training their talent how to do OO A&D.

So, into that void steps this book, GoF. It actually had come out a couple years earlier, intended as assistance to C++ programmers, because they hadn't developed quite the same mature class frameworks as Smalltalk had, but the upcoming generation of Java students were going to be a bigger market.

GoF helps people discover and articulate object patterns in a language-independent way. It also helps people implement OO within the confines of static data typing.

The authors spent a lot of time on format and presentation, and cross referenced their patterns for the sake of comparison. However, the way they have isolated these patterns into iconified examples has struck me as arbitrary and stifling.

OO is about dynamic binding, encapsulation, inheritance, and polymorphism. It's not about these 20 or so patterns and their permutations. If you understand the basic ideas about OO, then you don't need to memorize all these patterns. The building blocks are in the ideas. And that's not to take away from the fine analysis done by GoF, but rather to rebut the impression that GoF is a cast iron template.

The best way to learn OO is first hand, by downloading a free version of Smalltalk, observing and experimenting. Unfortunately though, C++ and Java are such that they don't always absorb OO architectural concepts seamlessly. Therefore, this book is a helpful guide for writing code (in C++ at least) which approximates. It's too bad the book was written only one year before Java's release, or they would have provided examples in Java as well.

A fine point that GoF raises is that inheritance is over-used. Too many people create deep, inflexible, hierarchical levels of inheritance. I prefer to see if there is some other way of associating objects, such as delegation. After all, inheritance can be perceived as a violation of encapsulation.

One final note about the proliferation of OO into other languages. With Java and C++, OO programmers can move out of Smalltalk's GUI IDEs, onto the command line and text files, and into Linux, GNU, vi, emacs, CVS, crontab, accept, tripwire, ssh, and a host of other fascinating utilities and languages.

I've had fun and I hope you have too.

Gang of Four is a book about which I have mixed feelings, both in terms of its inherit merits, as well as of its repercussions, but there's no doubt about its heralded place among A&D books. If you can suffer my meandering story, please read ahead. It's a review not only of GoF, but of the environment into which it was received.

In 1995, when this book was released, you could find infrastuctures using pure OO, but they tended to be specific companies which were unique enough to require distributed, interactive applications running concurrently on multiple operating systems. In an era of Microsoft and Netware, before the web, this was highly uncommon. Smalltalk was often the language of choice for distributed OO, with Gemstone as the OO database-app server.

It was an exciting time, because a lot of ideas which are now standard were first being conceived, sometimes in front of your eyes. People who were involved generally knew what they were doing, and were committed to OO. CORBA was being standardized and things pointed towards a rosy future for OO.

But in order to spread OO beyond its community, some bridges had to be crossed, and one was involving programmers from other languages. Another bridge was the emerging web. Sun Microsystems decided to trade its reputation in the Unix server market for a chance to bump off Microsoft in the end user market, envisioning a world of distributed network applications. Initially, they had wanted to license Visual Works Smalltalk from ParcPlace, but were unable to reach agreement.

Sun decided to retrofit a language called Oak that they had been working on in-house for distributed set-top boxes. They basically wanted to build a Smalltalk with C++ syntax and fixed data typing, with protocols for the web.

There were enough people drawn to Java by its emphasis on web distribution, rather than OO, that the language began introducing artifacts from procedural code, as evident in EJB, inner classes, a compromised MVC model for Swing, and unenforced encapsulation. The real fallout was when new Java developers began writing code and it wasn't OO at all. I remember one Wall Street project where the application consisted of one big class encapsulating lots of nested inner classes. This was architected by the premiere Java shop in Manhattan too. The general drift was the people running the Java shops were coming from Unix/C and didn't care much about OO, and they privately confided as much.

So, into that void steps this book, GoF. It actually had come out a couple years earlier, intended as assistance to C++ programmers, because they hadn't developed quite the same mature class frameworks as Smalltalk had. GoF helps people discover and articulate object patterns in a language-independent way. It also helps people implement OO within the confines of static data typing. The authors spent a lot of time on format and presentation, and cross referenced their patterns for the sake of comparison.

GoF offers the bold advice that inheritance is over-used. I agree. Too many people create deep hierarchical levels of inheritance. They are inflexible, somewhat arbitrary, and generally speaking I prefer to see if there could be some other way of associating one class with another, rather than inheritance. After all, inheritance can be perceived as a violation of encapsulation.

But the flip side of my appreciation of GoF is that too many people have not been encouraged to actually look at Smalltalk itself. It's one thing to look at a book, it's another to really see the ideal in practice. Also, I think there's some false perceptions out there that those who know GoF know OO and those who don't don't.

[One final note about the proliferation of OO. Up until Java, pure OO was generally Smalltalk, and that confined developers to Smalltalk IDE's, which are for the most part GUIs. With Java, programmers could move out onto the command line, text files, and into Linux, GNU, vi, and a host of fascinating utilities and languages, so it was a fair swap for me.]

Perhaps I've talked about OO, Java, Smalltalk, and industry issues too much in this review, but to me, GoF addresses the proliferation of OO across languages, and therefore the manner in which this has actually happened is part of my reaction to the book itself.

Gang of Four is a book about which I have mixed feelings, both in terms of its inherit merits, as well as of its repercussions, but there's no doubt about its heralded place among A&D books. If you can suffer my meandering story, please read ahead. It's a review not only of GoF, but of the environment into which it was received.

I began programming in Smalltalk in 1994, and by 1995 I had moved up quickly enough that I was working with GemStone, which is the definitive OO database-application server. You could find infrastuctures using pure OO, but they tended to be specific companies which were unique enough to require distributed, interactive applications running concurrently on multiple operating systems. In an era of Microsoft and Netware, before the web, this was highly uncommon.

It was an exciting time, because a lot of ideas which are now standard were first being conceived, sometimes in front of your eyes. People who were involved generally knew what they were doing, and were committed to OO. CORBA was being standardized and things pointed towards a rosy future for OO.

But in order to spread OO outside its community, some bridges had to be crossed, and one was how to involve programmers from other languages. Another bridge was the emerging web. Sun Microsystems decided to trade its reputation in the Unix server market for a chance to bump off Microsoft in the end user market, envisioning a world of distributed network applications. Initially, they had wanted to license Visual Works Smalltalk from ParcPlace, but at that time Smalltalk was so expensive, that ParcPlace declined to sell. ParcPlace upset a lot of people, because OO was going to take several uncertain steps back, from which it is still recovering.

As a result, Sun decided to retrofit a language called Oak that they had been working on in-house for distributed set-top boxes. They basically wanted to build a Smalltalk with C++ syntax and fixed data typing, with protocols for web distribution.

There were enough people drawn to Java by its emphasis on web distribution, rather than OO, that the language began including many artifacts from procedural code, as evident in EJB, inner classes, a compromised MVC model for Swing, and unenforced encapsulation. The real fallout was when new Java developers began writing code and it wasn't OO at all. I remember one Wall Street project where the application consisted of one big class encapsulating lots of nested inner classes. This was architected by the premiere Java shop in Manhattan too. The general drift was the guys running the Java shops were coming from Unix/C and didn't care much about OO, and in private they'd confide as much.

So, into that void steps this book, GoF. It actually had come out a couple years earlier, intended as assistance to C++ programmers, because they hadn't developed quite the same mature class frameworks as Smalltalk had. It also helps Smalltalkers perpare for implementing OO within the confines of static data typing. GoF helps people articulate, in a language-independent way, object patterns.

GoF should intrigue most OO architects. The authors spent a lot of time on its format and presentation. They cross referenced their patterns for the sake of comparison. It's interesting for me to see how they differentiated between factory models, and their examples of patterns in other languages. If you haven't coded in awhile, then this book will help jog your memory about various architectures.

In passing, GoF suggests that inheritance is often over-used. I agree. Too many people begin their object models with deep hierarchical levels of inheritance. It becomes inflexible, somewhat arbitrary, and generally speaking I prefer to see if there could be some other way of associating one class with another, rather than inheritance. After all, inheritance can be perceived as a violation of encapsulation.

But the flip side of my appreciation of GoF is that too many people have not been encouraged to actually look at Smalltalk itself. It's one thing to look at a book, it's another to really see the ideal in practice. Also, I think there's some false perceptions out there that those who know GoF know OO and those who don't don't.

[One final note about the proliferation of OO. Up until Java, pure OO was generally Smalltalk, and that confined developers to Smalltalk IDE's, which are for the most part GUIs. With Java, programmers could move out onto the command line, text files, and into Linux, GNU, vi, and a host of fascinating utilities and languages, so it was a fair swap for me.]

Perhaps I've talked about OO, Java, Smalltalk, and industry issues too much in this review, but to me, GoF addresses the proliferation of OO across languages, and therefore the manner in which this has actually happened is part of my reaction to the book itself.