|
Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series) (精装)
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
| Category:
Design patterns, Software development, IT, Technology |
| Market price: ¥ 558.00
MSL price:
¥ 548.00
[ Shop incentives ]
|
| Stock:
Pre-order item, lead time 3-7 weeks upon payment [ COD term does not apply to pre-order items ] |
MSL rating:
 Good for Gifts |
| MSL Pointer Review:
A modern classic in the literature of object-oriented development, it's a book of design patterns that describe simple and elegant solutions to specific problems in object-oriented software design. |
| If you want us to help you with the right titles you're looking for, or to make reading recommendations based on your needs, please contact our consultants. |
|
| |
AllReviews |
1 2   | Total 2 pages 11 items |
|
|
Ben Mofaz (MSL quote), Israel
<2007-01-11 00:00>
There is no question that design patterns are an important part of object-oriented development, and this is the definitive work on that topic. As good as it is, it does have its weaknesses, although some of them can be dismissed as points that are mere personal preference. For example, I would have preferred that the code examples be written in Java, but I would not penalise the book because of that. In addition, the style of the writing is very academic, but that is probably due to the authors' background and may even have been done deliberately.
However, I did sometimes find the UML diagrams more confusing than helpful, and the code samples were somewhat sparse. The explanations were largely adequate, although I sometimes found myself having to re-read the description of a pattern many times before I felt that I understood it. Even though, I would sometimes wind up being confused about the difference between two patterns or exactly what a pattern represented. Part of this I think has to do with the nature of design patterns - they are by definition somewhat high-level and abstract. Even so, I could not help but think that they could have been described better, which is why I only give this book four stars. |
|
|
Peter Adell (MSL quote), USA
<2007-01-11 00:00>
This book is a classic computer science text. This is probably the one computer book that every computer programmer and software developer should read. It will definitely have an immediate impact on the code you write. Unlike most computer books, which have a shelf measured in months, this book has lasted the test of time, and will likely be relevant for many years. (At least as long as object-oriented programming languages are used!)
This book uses C++ and Smalltalk to code the examples, but don't worry about that. There are plenty of books that are basically "rewrites" of this book using Java or other langauges, but it doesn't matter what language your programming. I recommend this book over any other patterns book because these guys invented the subject. The patters can be programmed in any language, and you don't have to be a C++ or Smalltalk expert to understand them. |
|
|
Nadahalli (MSL quote), India
<2007-01-11 00:00>
I came across this classic pretty innocuously. Some colleagues suggested a design patterns study group and from that day I was hooked. This book teaches you more about Object Oriented programming than all the other OO books combined.Each pattern opens up another facet of Object Oriented programming. Once you are done with all the patterns, and then, done with them again, and then, done with them again you feel the euphoria of having understood something so abstract, but at the same time so tangible and visible around us. Be it Java, C++ or any other OO language, your design ideas and orgranizations become incredibly elegant and simple. This, is something you learn and appreciate only if you have gone through this book. And, here, by "done with them", I mean a thorough study, sample implementations, production implementations and the ability to recognize that pattern with its subtle variations.
The GoF book ( Gang of Four ) is structured as a manual of sorts, and it requires some orderly study. Look up Design Patterns Study Group on Google. The study orders suggested there are worth mulling over. The simple patterns are easy enough to understand ( Factory method and the like ) and the complex ones ( Visitor ) can be digested with the understanding of the basic patterns.
Again, at the end of the book, ( there is so end to this book, though ) you might actually end up mastering OO coding.
Couple of possible criticisms on this book is that you begin to think in patterns for every problem. Which might not be entirely good, and this book doesnt encompass the full world of pure OO patterns ( collecting parameter, for example ). But its still THE book to start with.
It also helps that this book has become a standard of sorts and the terms and jargon presented in this book are highly visible in the OO design and programming world. Worth a Buy, Worth a dozen reads. |
|
|
Mike Buckingham (MSL quote), USA
<2007-01-11 00:00>
My only critique of the book is that it is very heavy on examples. It is all relevant and if you have the time to read and digest it all you will be a better programmer. However, there are more concise books that do a better job of distilling the important concepts of design patterns and books that provide better modern approaches. This is the type of book that you have to read in school becuase it is a classic. I would equate to classic literature like Homer or War and Peace. They are important in a scholarly sense if you wants a deep historic understanding of the topic. However, you can understand and use design patterns without reading other books and you will save a lot of time.
Another good analogy is the way calculus is taught in school. First they teach you in-depth complicated way. They take you through all the steps the inventor went through to come up with it. Then they show you the short cuts that are used in common practice. You have a better understanding of the topic because you know the hard way but you would be foolish not use the short cuts.
So you can read this book and get an in-depth understanding or you can skip this step and go straight the a concise book that shows you how patterns are used practically today. |
|
|
Gregory Bittar (MSL quote), USA
<2007-01-11 00:00>
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.
All cynicism aside, this book is the only comprehensive analysis of object-oriented design patterns, with examples from programming languages mainstream and obscure, and goes so far as to advance an abstract set which we can all share. Now, whether or not seasoned developers will toss their old semantics out in favor of these is debatable, but younger programmers may find this reference to be their generational touchstone. Architects of any stripe should find something to ponder within its pages. |
|
|
John Doorley (MSL quote), USA
<2007-01-11 00:00>
I have been doing real-time C/C++ systems for the last 25 years (out of a 40 year prog. career). The I have worked on systems have gotton bigger and bigger. The concepts of the Design Patterns books become more important to me as the systems got larger.
The point is that Design Patterns may seem irrelevant to programmers working on smaller projects.
It seems to me that the larger systems have more objects dedicated to work flow, collaboration, and policy than smaller systems. For example, a wireless switch project I worked on had radios, mobile stations, vlans, etc. but the majority of the system objects seemed to be dedicated to how these devices interacted rather than on support for the devices themseleves. Unfortunately, for this project, this behavior was stuffed into the classes associated with the devices. This caused class bloat and those annoying little "do nothing" classes.
The design patterns book gives suggestion about how to separate classes into smaller chunks while maintaining a rational and systematic collaboration. In my copies, those end of section for creational, structural and behaviorial pattern have little yellow postits for fast access.
To remember the behaviorial patterns, I came up with: crazy cat interest in mickey mouse on stacked salad tasty vitals.
One of the problems with C++, especially for real time use, is lack of a widely known set of classes that could serve to make design patterns "more real" to more RT C++ programmers. In the past 6 months I started to learn python/twisted/nevow for testing, tools, and personal organization (email, web site). Python and the class libraries that go along with use many design patterns, for example use of factories in web servers, templates for HTML parsers, blah, blah. Anyone who knows C++ will easily learn Python.
I own 2 copies of Design Patterns, one for home and one for work. |
|
|
Ashwini Asagam (MSL quote), USA
<2007-01-11 00:00>
A reference manual of best practices in software application design. Best design practices identified and categorized as patterns makes communication and application of the practice easier and more effective. It is not difficult for a somewhat experienced developer to learn these patterns and apply them in day-to-day work, given the content of the book and presentation. Each pattern is discussed with information relating to its applicability, participants, consequences, sample code, known uses, etc.
If you know how traditional mechanical/electrical/civil engineers work, they always have a reference design manual handy. This book serves the same purpose to a good extent.
If you know how traditional mechanical/electrical/civil engineers work, they always have a reference design manual handy. This book serves the same purpose to a good extent.
The only complaint I may have of this book is the nature of examples (Singleton pattern example is one). I wish the authors used more business application examples much like a reservation or purchase order system as it would appeal to a larger developer base (IMHO). |
|
|
Chris Coakley (MSL quote), USA
<2007-01-11 00:00>
A lot of people who work in Industry have left this book on the shelf, "because I picked it up and didn't see anything really new." That is the whole point behind this book. Design Patterns creates a common language for discussing designs that are common enough to have a core "pattern" modelled after them. By naming the patterns, old programmers will have names to express their designs so that others can understand them in a programming language independent way. If you are a new programmer, a lot of these ideas may be new to you, but if nothing is new, there is still value to this book (the now-standard names for these patterns). This book does an excellent job of elevating object oriented design discussion beyond merely talking about "inheritence" and "polymorphism", and into talking about the tradeoffs of the "Singleton" vs the "Document" pattern for global variable replacement (and why the Command pattern should always be used in multithreaded environments). That being said, if you are an experienced programmer, don't expect a lot of new material in here, feel free to skim chapters, etc. Just make sure you learn the names for the things you do every day so that the rest of the programmers on your team can understand you! |
|
|
Haldar (MSL quote), USA
<2007-01-11 00:00>
I never thought I would be saying anything different from anybody by praising this book, that's why I never got around to writing a review for this book though I have used the concepts of this book in many projects, but recently I came across some very harsh review of this book and found that to be very very misleading, so I basically wanted to straighten things up.
First of all, I would not go even near claiming this book would add value to everyone (though I might have made this very mistake had I written this review a year back), this book mainly targets the software architects who are responsible for designing large or fairly large software applications ground up, or who redesigns or enhances an existing system to make it feature rich or performance-enhanced or less unweildy (refactoring more or less). This book is just not the right stuff for head-down coders who want to remain that way.
I am developing software for over 6 years, I'll say for the first three or so years I have played more of the role of a developer that the role of an architect, but then I moved on to architect position and I have found that knowledge of Design patterns has helped me considerably. I'm not saying knowledge of design patterns is the only thing you need to develop a flexible and robust architecture, but it at least ensures you do not make any egregious mistakes in addressing well-known and frequently occuring problems, it provides a baseline, you obviously need to know the innards of the technology you'd finally be using for development to provide a good architecture but you really can't just go ahead and start typing up your code unless it's a miniscule application you are developing.
Keeping all these in mind, I would not suggest this book to everyone, though I would love to, I do recognize the fact that not everyone focuses on the same area, different people do specialize in different areas and I respect others' rights to think completely differently than I do, so I'll suggest this to software architects, present/would be/wanna bes, those who want to keep out of that area are better off by keeping away from this book, the only suggestion I have for them is that they should not say that this book is worthless just for the fact that it's not been written for them. |
|
|
Soren Meyer (MSL quote), Germany
<2007-01-11 00:00>
This book is a catalog of 23 more or less useful object oriented design patterns in more or less wide spread use. Don't get me wrong, I do like the book's intention of introducing a common vocabulary of solutions to particular engineering problems and it is certainly valuable having these solutions collected and organized in one place. However, I think it is unnecessarily dry and hard to read. The source code examples on the other hand are written in easily understandable C++ with brief mentions of existing implementations or implementation possibilities in different languages. I would have wished for more and more elaborate examples though. The authors often mention the possibility for mixing several patterns to archive their combined strengths, but seldom give code examples demonstrating this - thus leaving the harder problems to the reader. I would have liked less emphasis on the sometimes obscure and outdated 'known uses' section for each pattern - which cites where the pattern has successfully been applied - in exchange for more actual code examples. Sometimes the 'known uses' section reads like an excuse for including that particular pattern, which should be unnecessary, the use should be self evident or the pattern omitted. That said, I still haven't found a use for some of the more esoteric patterns in my everyday designs and application of C++. The book is still a valuable reference, since many patterns (factory, singleton, observer, command) really are in widespread use and you don't want to miss out on their usefulness and seem ignorant in discussions about them. |
|
|
|
1 2 | Total 2 pages 11 items |
|
|
|
|
|
|
