Design Patterns Explained: A New Perspective on Object Oriented Design, 2nd Edition (Software Patterns) 2nd Edition
Use the Amazon App to scan ISBNs and compare prices.
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.
Frequently bought together
Customers who viewed this item also viewed
From the Inside Flap
December, 2000updated May, 2004From Artificial Intelligence to Patterns to True Object OrientationMy journey into design patterns had a different startingpoint than Alan’s but we have reached the same conclusions: · Pattern-based analyses make you a more effective and efficientanalyst because they let you deal with your models more abstractly and becausethey represent the collected experiences of many other analysts. · Patterns help people to learn principles of object orientation.The patterns help to explain why we do what we do with objects. I started my career in artificial intelligence (AI) creatingrule-based expert systems. This involves listening to experts and creatingmodels of their decision-making processes and then coding these models intorules in a knowledge-based system. As I built these systems, I began to seerepeating themes: in common types of problems, experts tended to work in similarways. For example, experts who diagnose problems with equipment tend to lookfor simple, quick fixes first, then they get more systematic, breaking theproblem into component parts; but in their systematic diagnosis, they tend totry first inexpensive tests or tests that will eliminate broad classes ofproblems before other kinds of tests. This was true whether we were diagnosingproblems in a computer or a piece of oil field equipment. Today, I would call these recurring themes patterns. Intuitively, I began to look for these recurring themes as I was designing newexpert systems. My mind was open and friendly to the idea of patterns, eventhough I did not know what they were. Then, in 1994, I discovered that researchers in Europe hadcodified these patterns of expert behavior and put them into a package thatthey called Knowledge Analysis and Design Support, or KADS. Dr. KarenGardner, a most gifted analyst, modeler, mentor, and human being, began toapply KADS to her work in the United States. She extended the European’s work to apply KADS to object-orientedsystems. She opened my eyes to an entire world of pattern-based analysis anddesign that was forming in the software world, in large part due to ChristopherAlexander’s work. Her book, Cognitive Patterns (CambridgeUniversity Press, 1998), describes this work. Suddenly, I had a structure for modeling expert behaviors withoutgetting trapped by the complexities and exceptions too early. I was able tocomplete my next three projects in less time, with less rework, and withgreater end-user satisfaction, because: · I could design modelsmore quickly because the patterns predicted for me what ought to be there. Theytold me what the essential objects were and what to pay special attention to.· I was able to communicatemuch more effectively with experts because we had a more structured way to dealwith the details and exceptions. · The patterns allowed meto develop better end-user training for my system because the patternspredicted the most important features of the system. This last point is significant. Patterns help end-usersunderstand systems because they provide the context for the system, why we aredoing things in a certain way. We can use patterns to describe the guidingprinciples and strategies of the system. And we can use patterns to develop thebest examples to help end-users understand the system. I was hooked.So, when a design patterns study group started at my place ofemployment, I was eager to go. This is where I met Alan who had reached asimilar point in his work as an object-oriented designer and mentor. The resultis this book. Since writing the first edition, I have learned just how deeplythis approach to analysis can get into your head. I have been involved in manydifferent sorts of projects, many outside of software development. I look at systemsof people working together, exchanging knowledge, exchanging ideas, living inremote places. The principles of patterns and object-orientation have stood mewell here, too. Just as in computer systems, there is much efficiency to begained by reducing the dependencies between work systems. I hope that the principles in this book help you in your ownjourney to become a more effective and efficient analyst.James R. Trott
December, 2000updated May, 2004A Note About Conventions Used in This BookIn the writing of this book, we had to make severalchoices about style and convention. Some of our choices have surprised ourreaders. So, it is worth a few comments about why we have chosen to do what wehave done. Approach Rationale First person voice This book is a collaborative effort between two authors. We debated and refined our ideas to find the best ways to explain these concepts. Alan tried them out in his courses and we refined some more. We chose to use the first person singular in the body of this book because it allows us to tell the story in what we hope is a more engaging and natural style. Scanning text We have tried to make this book easy to scan so that you can get the main points even if you do not read the body, or so that you can quickly find the information you need. We make significant use of tables and bulleted lists. We provide text in the outside margin that summarizes paragraphs. With the discussion of each pattern, we provide a summary table of the key features of the pattern. Our hope is that these will make the book that much more accessible. Code examples This book is about analysis and design more than implementation. Our intent is to help you think about crafting good designs based on the insights and best practices of the object-oriented community, as expressed in design patterns. One of the challenges for all of us programmers is to avoid going to the implementation too early, doing before thinking. Knowing this, we have purposefully tried to stay away from too much discussion on implementation. Our code examples may seem a bit lightweight and fragmentary. Specifically, we never provide error checking in the code. This is because we are trying to use the code to illustrate concepts.Examples in C++ and C# are also present at this site. Strategies and
principles Ours is an introductory book. It will help you be able to get up to speed quickly with design patterns. You will understand the principles and strategies that motivate design patterns. After reading this book, you can go on to a more scholarly or a reference book. The last chapter will point you to many of the references that we have found useful. Show breadth and give a taste We are trying to give you a taste for design patterns, to expose you to the breadth of the pattern world but not go into depth in any of them (see the previous point). Our thought was this: If you brought someone to the USA for a two-week visit, what would you show them? Maybe a few sites to help them get familiar with architectures, communities, the feel of cities and the vast spaces that separate them, freeways, and coffee shops. But you would not be able to show them everything. To fill in their knowledge, you might choose to show them slide shows of many other sites and cities to give them a taste of the country. Then, they could make plans for future visits. We are showing you the major sites in design patterns and then giving you tastes of other areas so that you can plan your own journey into
patterns. How to read Java code if you are a C# developer All of the code examples in this book are written in Java. If you do not have experience with Java but can read C#, here is what you need to know: Java uses the words extends and implements to denote a class that extends another class or one that implements an interface, rather than the colon (":"). which is used for both purposes in C#.. Hence, in Java, you would see: public class NewClass extends BaseClass or public class NewClass implements AnInterface while in C# you would see: public class NewClass : BaseClass or public class NewClass : AnInterface All methods are virtual in Java and therefore you don’t specify whether they are new or overridden. There are no such keywords in Java, all subclass methods override any methods they reimplement from a base class. Although there are other differences, they won’t show up in our code examples. How to read Java code if you are a C++ developer This is a little more difficult, but not much more. The most obvious difference is the lack of header files. But how to read the combined header-code file is self-evident. In addition to the C# differences, Java never stores objects on the stack. Java stores objects in heap storage and stores variables that hold references (pointers) to objects on the stack. Every object must be created with a “new”. Hence, in Java you would see: MyClass anObject= new MyClass(); anObject.someMethod(); while in C++ you’d see: MyClass *anObject= new MyClass(); anObject->someMethod(); Thus, Java code looks like C++ code if you add a ‘*’ in the declaration of every variable name that references an object and convert the ‘.’ to a ‘->’. FeedbackDesign patterns are a work in progress, a conversationamong practitioners who discover best practices, who discover fundamentalprinciples in object orientation.We value your feedback on this book:· What did we do well or poorly?· Are there errors that need to be corrected?·New in the Second EditionThis second edition represents several changes andimprovements over the first edition. It reflects what we have learned fromusing and teaching design patterns over the last several years as well as thegenerous and valuable feedback we have received from our readers. Here is a highlight of changes: · Reorders chapters, moving the Strategy pattern earlier· Expands the discussion about Commonality and Variability Analysis(CVA)· Adds a synthesis of eXtreme Programming and design patterns· Makes all code examples complete rather than notional orfragments. All code is in Java. The website also has C# and C++ examples· Explains why the use of factories as objectinstantiators/managers is extremely useful.· Added one design pattern not in the Gang of Four: the Object Poolpattern.· Added a discussion of the pitfalls of patterns and the caution totreat patterns as guides to help you think. Patterns are not truth! We also made numerous small corrections in grammar andstyle.
From the Back Cover
"One of the great things about the book is the way the authors explain concepts very simply using analogies rather than programming examplesthis has been very inspiring for a product I'm working on: an audio-only introduction to OOP and software development."
"...I would expect that readers with a basic understanding of object-oriented programming and design would find this book useful, before approaching design patterns completely. Design Patterns Explained complements the existing design patterns texts and may perform a very useful role, fitting between introductory texts such as UML Distilled and the more advanced patterns books."
Leverage the quality and productivity benefits of patternswithout the complexity! Design Patterns Explained, Second Edition is the field's simplest, clearest, most practical introduction to patterns. Using dozens of updated Java examples, it shows programmers and architects exactly how to use patterns to design, develop, and deliver software far more effectively.
You'll start with a complete overview of the fundamental principles of patterns, and the role of object-oriented analysis and design in contemporary software development. Then, using easy-to-understand sample code, Alan Shalloway and James Trott illuminate dozens of today's most useful patterns: their underlying concepts, advantages, tradeoffs, implementation techniques, and pitfalls to avoid. Many patterns are accompanied by UML diagrams.
Building on their best-selling First Edition, Shalloway and Trott have thoroughly updated this book to reflect new software design trends, patterns, and implementation techniques. Reflecting extensive reader feedback, they have deepened and clarified coverage throughout, and reorganized content for even greater ease of understanding. New and revamped coverage in this edition includes
- Better ways to start "thinking in patterns"
- How design patterns can facilitate agile development using eXtreme Programming and other methods
- How to use commonality and variability analysis to design application architectures
- The key role of testing into a patterns-driven development process
- How to use factories to instantiate and manage objects more effectively
- The Object-Pool Patterna new pattern not identified by the "Gang of Four"
- New study/practice questions at the end of every chapter
Gentle yet thorough, this book assumes no patterns experience whatsoever. It's the ideal "first book" on patterns, and a perfect complement to Gamma's classic Design Patterns. If you're a programmer or architect who wants the clearest possible understanding of design patternsor if you've struggled to make them work for youread this book.
© Copyright Pearson Education. All rights reserved.
There was a problem filtering reviews right now. Please try again later.
Other reviews have complained about the lack for code in this book. If you are looking for a book to show you how to write code that implements a specific pattern in a specific language this book is not for you. This book is a higher level book that focuses on the concepts of good design that are true for all object oriented languages. There are other books that go into the specifics of various languages.
I found this book a true pleasure to read, and recommend it above the original GOF book. It really makes patterns incredibly easy to understand and apply in the right context, instead of just blindly using them because they are the next cool thing in Software Engineering.
Whilst the 'GoF book' is still a vital book, it is more of reference than something that should be read cover-to-cover. Buy this book first, and then get the 'GoF Book', once you have read this book.
-less dense than GoF
-in-depth real-world case studies showing how patterns provided solutions
-writing style is in the vein of "inspirational" or "self-help" books - to me it's unsuitable for a technical subject (author talks about how patterns have "changed his life", like a religion or something).
-the author comes across as an evangelist, treating the GoF text as dogma. Patterns, like any other technique, are not magic and have their own set of pros/cons; the author presents them as the be-all end-all solution for all software engineering problems.
-There is a *lot* of superfluous space in this book - huge margins, big font, before-and-after chapter summaries ("here's a two-page list of what I'm going to tell you", followed by the chapter contents, followed by "here's a two-page list of what I just told you.")
The pros outweigh the nitpicks listed above, but I highly suggest following this up with the original GoF text - you may find it more digestible after this appetizer.
Top international reviews
What I didn't realise is that the bulk of this book, ie the parts that describe the patterns themselves, does nothing more than rehash what the GoF did, but not as well. The depth (or lack of) that this book covers was in the first few pages of the GoF's description of each pattern, and the heavy stuff that the GoF added was missed out from this book altogether. What's worse is that the GoF had far better examples that made the patterns easier to understand. With the descriptions here, you just started to get the idea of what the pattern was about when the chapter ended. You were left with a feeling of being dropped right at the crucial moment.
To make matters worse, the "dozens of code examples" promised on the back of the book turned out to be very short and unhelpful. Whilst it's important to concentrate on only those bits of code that are relevant to the issue being discussed, you need enough code to see what's going on. This book has very little. In fairness, the web site has a lot more code to download, but the book should have had more code shown, instead of forcing you to wade through the downloaded files.
If you just want to learn the patterns, then you're WAY better off with the GoF book, and just skip anything you find too heavy.
This book spends far too much time on irrelevant points (like discussing things he's not going to cover). For example, it spends a whole chapter describing an example situation, making out that it's going to be a major part of the book, but then you find that it is then not used very much in the rest of the book. The bits that re used could have been described in one paragraph. What a waste of time!
The one thing that the GoF book doesn't do, that this one attempts to do is explain how to decide which pattern to use. This is a very important issue, as learning the patterns is really only the beginning. You need to know how and when to apply them. This books spends some time describing how to analyse your problem domain, and how to decide which patterns might be appropriate.
Unfortunately, this is all done in a fairly vague manner, and so it far less useful than it could have been. Had this part been done well, the book would have been worthwhile, even with my other complaints. However, as this part was fairly unclear, I don't think the book warrants more than three stars. The authors keep dropping hints about their courses, but if this is the way they teach, I can't see the courses being much good. I certainly wouldn't pay money to have them teach me!
It could be that repeated reading of the analysis section of the book might eventually help, but I don't have the time or interest to bash through it over and over again in the hope that it make become clearer. I'm sure there are better ways to learn this stuff.
A great disappointment.
A pattern is a solution that comes up enough times that it might as well have a name. By their very nature patterns are obvious solutions if you understand the fundamental principles of software engineering and think about the problem for long enough. The problem almost always defines the solution. Unfortunately this book tries to describe a new perspective on Object Oriented design that frankly just isn't actually new. As with any technology, how it is actually used in practise evolves over time and changes from how it was first envisaged. Whilst reading this book a colloquial expression often came to mind that Dr Watson could have said to Sherlock Holmes if he had just stated the blindingly obvious.
This is most definitely not a reference book. You have to wade through bumpf about design and the personal experiences of the authors to find the sections describing specific patterns. Concise is not a word that I would use to describe this book. It's useful to know the names of patterns because it aids communication with other engineers, but if you want to find out what someone else is referring to then it will be faster to use wikipedia.
The only thing that I really learnt from this book was about the pitfall of implementing double checked locking in Java. Unfortunately Wikipedia gave a much more useful explanation.
The authors essentially teach the reader how to design software better. They walk the reader through various approaches to a systems design example throughout the book, finally culminating with the approach of combining software patterns with CVA (Commonality and Variability Analysis). It is just so obvious but no-one ever seemed to think of it before.
From reading this book I now have a lot more clarity in thinking through the analysis and design of software and am producing implementations that are far more maintainable. For that I cannot thank the authors enough.
In summary : GET THIS BOOK!
Se cercate un testo rivolto al completo neofita andate su Head First Design Patterns che fa sempre esempi molto semplici, eliminando i dettagli e concentrandosi sugli aspetti importanti.
It certainly has a lot of explanation in it, but verbose does not necessarily mean clear. I found that the explanations were just too long winded for me to grasp the essence of each pattern. I got lost in the rambling.
I gave up when I reached the Bridge pattern chapter. This comes directly after the Strategy pattern chapter and although the patterns overlap to a very great degree it immediately starts describing yet another example problem domain in excruciating detail. As soon as I started reading the problem I thought, OK, so we can use the Strategy pattern here, it's exactly the same problem. The Strategy is never mentioned in the entire Bridge chapter. The same problems of using inheritence to solve multiple heirachies are labouriously explained once more, and the Bridge is given as the solution, which seemed identical to the Strategy. I ended up with no clue as to the difference between the two patterns after trolling through an incredible 32 pages on the Bridge!
I have since obtained a copy of the GoF book and was staggered to find that just by looking at the Bridge class diagram and reading the 2 page Motivation section I was instantly able to understand the difference. The GoF book seems far clearer in every respect. I'm not sure if this is because I've been a developer for many years, it may be that beginners find it more obscure, but I found the concise, clearly seperated explanations brilliant.
So for me as an experienced developer, the GoF book wins easily over this one. YMMV.
Just like the majority of books in the field of computing, this one suffers from being written in an over-trivialised fashion and language and lacking a grounded logical structure.
In detail it suffers from the following issues. The book claims thinking in patterns and new paradigm of design, yet it merely repeats one and the same idea over and over again in a fairly unstructured way, which could be introduced and explained just once. The over-trivialised language, the quality of examples, the narrative, the overuse of the first form make it a pain to read if the reader has a habit of reading literature in general. The explanations are too wordy yet not too insightful, quite often they come to repeating what has been said before a number of times. Code examples could be more involved, more consistent and more accurate (in particular one should not be seeing 'myObject' variable names in a code snippet addressing a particular problem). Finally, the visual presentation of the book is quite poor: too many font styles and sizes on one page, yet not syntax highlight in code examples; the quality of tables and diagrams is poor, there is too much whitespace and repetitions of the table of content so the book could really be one third of the current size if formatted properly.