- Buy this product and stream 90 days of Amazon Music Unlimited for free. E-mail after purchase. Conditions apply. Learn more
Design patterns : elements of reusable object-oriented software Hardcover – 31 Oct 1994
- Choose from over 13,000 locations across the UK
- Prime members get unlimited deliveries at no additional cost
- Find your preferred location and add it to your address book
- Dispatch to this address when you check out
There is a newer edition of this item:
Special offers and product promotions
Frequently bought together
Customers who viewed this item also viewed
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.
Would you like to tell us about a lower price?
If you are a seller for this product, would you like to suggest updates through seller support?
Design Patterns is based on the idea that there are only so many design problems in computer programming. This book identifies some common program-design problems--such as adapting the interface of one object to that of another object or notifying an object of a change in another object's state--and explains the best ways (not always the obvious ways) that the authors know to solve them. The idea is that you can use the authors' sophisticated design ideas to solve problems that you often waste time solving over and over again in your own programming.
The authors have come up with some ingenious ways to solve some common vexations among object-oriented programmers. Want to build a page-layout program that embeds inline images among characters of various sizes? How about building a program that converts files of one format to another? Chances are, some programmer already has thought of a better solution than you will and the recipes you need are here. Solutions are presented in generalised diagrams of data and logic structures. The idea is that you can take the concepts presented here and adapt them--in whatever language you use--to your individual situation. You may have to read some of the chapters several times before you fully understand them, but when you find a solution in this book, it will make your job easier and your results more elegant. --Jake Bond
*Capturing a wealth of experience about the design of object-oriented software, four top-notch designers present a catalog of simple and succinct solutions to commonly occurring design problems. Previously undocumented, these 23 patterns allow designers to create more flexible, elegant, and ultimately reusable designs without having to rediscover the design solutions themselves. *The authors begin by describing what patterns are and how they can help you design object-oriented software. They then go on to systematically name, explain, evaluate, and catalog recurring designs in object-oriented systems. With Design Patterns as your guide, you will learn how these important patterns fit into the software development process, and how you can leverage them to solve your own design problems most efficiently.See all Product description
Customers who bought this item also bought
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.