Design Patterns CD: Elements of Reusable Object-Oriented Software (Professional Computing) CD-ROM – Audiobook, 21 May 1998
Customers who viewed this item also viewed
Related items to consider
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Published in 1995, Design Patterns: Elements of Reusable Object-Oriented Software has elicited a great deal of praise from the press and readers. The 23 patterns contained in the book have become an essential resource for anyone developing reusable software designs. In response to a great number of requests from readers of the book and from the object-oriented community as a whole, these designs patterns, along with the entire text of the book, are being made available on CD. This electronic version will enable students to install the patterns directly onto a computer and create an architecture for using and building reusable components. Produced in HTML format, the CD is heavily cross-referenced with numerous links to the online text.
From the Back Cover
Now on CD, this internationally acclaimed bestseller is more valuable than ever! Use the contents of the CD to create your own design documents and reusable components. The CD contains:
- 23 patterns you can cut and paste into your own design documents
- Sample code demonstrating pattern implementation
- Complete Design Patterns content in standard HTML format, with numerous hyper-linked cross-references
- Access through a standard web browser
- Java-based dynamic search mechanism, enhancing online search capabilities
- Graphical user environment, allowing ease of navigation
First published in 1995, this landmark work on object-oriented software design presents a catalog of simple and succinct solutions to common design problems. Created by four experienced designers, the 23 patterns contained herein have become an essential resource for anyone developing reusable object-oriented software. In response to reader demand, the complete text and pattern catalog are now available on CD-ROM.
The authors first describe what patterns are and how they help you in the design process. They then systematically name, explain, evaluate, and catalog recurring designs in object-oriented systems. All patterns are compiled from real-world examples and include code that demonstrates how they may be implemented in object-oriented programming languages such as C++ and Smalltalk. Readers who already own the book will want the CD to take advantage of its dynamic search mechanism and ready-to-install patterns.
The authors are internationally recognized experts in the object-oriented software field.
0201634988B04062001 See all Product description
84 customer reviews
Review this product
Read reviews that mention
There was a problem filtering reviews right now. Please try again later.
In short, yes it is still worth reading. Definitely so. Designing class structures is a significant part of most major software engineering projects, and doing it well reduces friction throughout the project, now and in future iterations. Whilst modern reactive, functional techniques subsume some of GOF or make knowledge of it unnecessary for the application developer, the API's and libraries these tools are built on almost always use patterns from GOF, as do other tools and libraries. Knowing those patterns makes using the libraries easier.
What's more, the book clearly makes the case and explains the value of concepts common to good software engineering, object oriented and otherwise. Decoupling, encapsulation, clearly defined responsibilities and others are all explained.
Of course, patterns are no panacea. You can make a good argument that design patterns are only necessary because of weaknesses in the languages used, that the need for them disappears in modern languages (and old, good, good-old languages like Common Lisp):
"The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write." (Paul Graham)
The Strategy pattern is a clear example of this, wrapping up functions in an object - and only necessary in languages which do not treat functions as first class entities in their own right. And using Singleton is generally accepted as a terrible idea.
(As an aside, Visitor is also sometimes presented as another unnecessary pattern whose motivation disappears if you use a good language - Scala, Groovy and C# come to mind, Wikipedia lists more. I'm less convinced by this claim, multiple dispatch is complex and easy to misunderstand. Explicit use of a visitor takes more typing but may be clearer.)
The book has clearly dated in other ways. The diagrams aren't UML (the book predates it!). The book depends on customs instead of what are now language-level features like interfaces. The heavy use of inheritance and subclassing is antiquated. A (to modern ears) obscure focus on micro-optimisation, warning that some patterns require instantiation of more objects and that this could be a performance concern. There is no consideration of concurrency and dependency injection doesn't get a look in. The absence of testing, although use of the patterns often presciently enables it much more than the "un-patterned" alternatives.
So there you have it: GOF is a hero, complete with tragic flaws. Well worth reading, but read it with the knowledge that a lot has changed in the last 20 years. Modern languages make some patterns redundant. There are other problems that patterns don't address. But for better or worse, I still find myself thinking in patterns most days of the week.
I've re-read this book so many times in my career and watched as it's contents went from obscure, to fad and overused reference to where I think it should always have been, an accepted classic containing great wisdom.
Study it, learn from from it, implement things they way it suggests - then learn that it is not dogmatic. Simply use it to help shape your software solutions into recognisable forms that can be maintained and evolved over time.
- Programming languages. I do vast majority of my coding in Java, sometimes I code in another JVM languages. This book provides examples in C++ and/or Smalltalk. Even more, this book was written before Java was a thing! This has to have an impact on how easy to follow are some of the examples. If you write Java 8 code, I bet you know what is the difference between external and internal iterator. At the same time, C++ friends will probably be less obvious to you, and the concept of e.g. enum-based singletons will not be mentioned at all. If only someone could write this book once again, but focus on Java-centric point of view.
- GUI-based examples. For nearly all the patterns, there is a GUI-related example. I am deeply alergic to GUI development and would appreciate more examples relating to backend functionalities.
- Didn't we evolve since then? Many of these design patterns are explicitly targetting challenges around excessive memory utilisation and other past limitations. We can do better now. Same constraints still exist, but are applicable to a very different extent. I can see people blindly following some of these patterns today in the field, with very little reflection upon the actual problem they are trying to solve. Today good programming is frequently not about making the application consume less memory, but about making it easier to understand and change. The problems we are trying to solve have changed, therefore the solutions we apply need to change as well. Keep it in mind while reading this book - not all of that is of equal value today, as it was when this book was first published. This takes us swiftly to the next point, which is...
- The pattern catalogue. While many of these design patterns are still valuable these days, there may be others which are more valuable. Just compare and contrast the builder pattern, as described in this book vs the one described many years later by Joshua Bloch.
My recommendation - read this book if you haven't done it already. Learn all the good things, just don't forget the world has moved on since then.
Every team who use object-orientation should have a copy in the office to refer to.
If you want a softer read, there is a Head First book on design patterns - but I would still recommend having a copy of this book to refer to when you want to implement and adapt a pattern in real life.