- Paperback: 416 pages
- Publisher: Addison-Wesley Professional (November 18, 2002)
- Language: English
- ISBN-10: 0201379430
- ISBN-13: 978-0201379433
- Product Dimensions: 7.3 x 0.8 x 9 inches
- Shipping Weight: 1.4 pounds (View shipping rates and policies)
- Average Customer Review: 17 customer reviews
- Amazon Best Sellers Rank: #670,515 in Books (See Top 100 in Books)
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.
Object Design: Roles, Responsibilities, and Collaborations
Use the Amazon App to scan ISBNs and compare prices.
Fulfillment by Amazon (FBA) is a service we offer sellers that lets them store their products in Amazon's fulfillment centers, and we directly pack, ship, and provide customer service for these products. Something we hope you'll especially enjoy: FBA items qualify for FREE Shipping and Amazon Prime.
If you're a seller, Fulfillment by Amazon can help you increase your sales. We invite you to learn more about Fulfillment by Amazon .
"Enlightenment Now: The Case for Reason, Science, Humanism, and Progress"
Is the world really falling apart? Is the ideal of progress obsolete? Cognitive scientist and public intellectual Steven Pinker urges us to step back from the gory headlines and prophecies of doom, and instead, follow the data: In seventy-five jaw-dropping graphs, Pinker shows that life, health, prosperity, safety, peace, knowledge, and happiness are on the rise. Learn more
Frequently bought together
Customers who bought this item also bought
Customers who viewed this item also viewed
From the Back Cover
If you create software using object-oriented languages and tools, then Responsibility-Driven Design has likely influenced your work. For over ten years Responsibility-Driven Design methodology has been the standard bearer of the behavioral approach to designing object-oriented software. Object Design: Roles, Responsibilities, and Collaborations focuses on the practice of designing objects as integral members of a community where each object has specific roles and responsibilities. The authors present the latest practices and techniques of Responsibility-Driven Design and show how you can apply them as you develop modern object-based applications.
Working within this conceptual framework, Rebecca Wirfs-Brock and Alan McKean present how user requirements, system architecture, and design patterns all contribute to the design of an effective object model. They introduce a rich vocabulary that designers can use to discuss aspects of their designs, discuss design trade-offs, and offer practical guidelines for enhancing the reliability and flexibility of applications. In addition, case studies and real-world examples demonstrate how the principles and techniques of Responsibility-Driven Design apply to real-world software designs.
You'll find coverage of such topics as:
As all experienced designers know, software design is part art and inspiration and part consistent effort and solid technique. Object Design: Roles, Responsibilities, and Collaborations will help all software designers--from students to seasoned professionals--develop both the concrete reasoning skills and the design expertise necessary to produce responsible software designs.
About the Author
Rebecca Wirfs-Brock is founder of Wirfs-Brock Associates. She consults with clients on actual architecture and design projects as well as development practices and methods. She is the originator of the set of development practices known as Responsibility-Driven Design. Among her widely used inventions are use case conversations and object role stereotypes. She was lead author of the classic work Designing Object-Oriented Software (Prentice-Hall, 1990).
Alan McKean is a respected object technology educator and cofounder of Wirfs-Brock Associates. His classes have introduced thousands of developers to object-oriented design and programming and his instructional techniques have been widely adopted by other educators. An experienced programmer, speaker, and instructor, Alan has developed curricula in object-oriented design, programming, and distributed object systems.
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
The book's layout and illustrations present its content well. UML diagrams, for example, use one color and typeface for the actual UML notation. The same diagrams use a different color and typeface for notes that explain the UML. Unlike other books, there's no confusion about which is the tool and which describes the tool. The text is gentle and reasonably jargon-free, but I think it over-does the friendliness in places. In discussing a program's normal and exception handling behavior, the term "happy path" described the execution in the absence of errors. The term may be evocative, but is just a bit hard to take seriously.
The sequence of topics makes good sense. It starts with the idea of a "responsibility," the basic unit of application logic. The authors develop this into strategies for defining objects, defining relationships between objects, and defining the control strategies that implement those relationships. They continue on through error handling (reliability) and extensibility - handling of future features. Throughout, the authors keep a moderate, pragmatic tone, free of name-brand methodology. That's a good thing, since the real focus is on basic skills and decision criteria.
One aspect of this book is just a little confusing. It's definitely aimed at educating a new OO designer, but it doesn't lay out its educational objectives or plan very clearly. It certainly lacks the didactic rigor of a textbook. It would make a good supplementary text, though, and it might be very helpful to a novice working with more experienced developers. Best of all, it refers to additional texts (including Strunk and White!) that will help claify the programs as well as communication with other members of the programming team.
This book is great for anyone starting OO design on their own. It's also good for classroom students who just aren't getting it from their regular instructor and text. Experienced developers won't find much new here, except very clear descriptions of how much error handling or flexibility is enough.
What's strange about the wording of this book is, the more vague the language, the more you ought to pay attention. It's vague because of its timelessness and universal application, not because they wanted to add pages to the size of the book. However, because of the general scope of much of the advice, you won't fully understand the gravity of its truthfulness until you fail to comply and have to come crawling back. It is the Proverbs of OOD. Remember, this book is the definition of a process; an approach to structuring logic into roles.
While some developers never seem to catch on, fast forward a few years in the life of an insightful developer and many of the RDD principles will have already been adopted. Reading this book at a later stage will seem like pure confirmation of all of your mistakes.
Using objects does not equal OOD.
If you're new to OOD, this book is indispensable and should be read immediately after learning the concept of a type or class. The entire concept can be condensed into a simple statement; if you don't build a society of roles that interact and behave in a "moral" object neighborhood, you're going to have magic procedural code that is burdened by all of the same complexities, but they will be invisible. Complexity is ever present, it's the strategy taken to manage and encapsulate the complexity that's important. What role-based object modeling provides is an additional layer of abstraction over the data entity/artifact context.
Those who don't utilize RDD will dramatically reduce code reusability, conceptual comprehension, process flow validation identification, developer and business agent understanding, modular decoupling, domain context definition, business rule execution, persistence schema flexibility, scaling, parallel programming, separation of concerns, command query separation, and vocabulary purity to name just a few aspects.
Without RDD you might as well toss out SOLID and GRASP while you're at it.
Domain Driven Design shares many of the SOLID principles of RDD, yet at a higher level, but RDD is perfect for pairing manifest models to domain contexts.
RDD gives business aware personnel like PM's and higher ups a design vocabulary to understand an implementation while guiding the technical choices of the development team.
If you're a developer, and you're having to think about the principles of responsibility, data governance, reusability, testability, scope, ect... while you're in the middle of writing a functional operation, you're doing it wrong, that kind of thinking should have been done before hand.
This book is a big "duh" for those who learned it on their own, but absolutely invaluable for anyone just getting started (it is comparable to warp drive for your marketability).
Some developers are perpetually comfortable slapping behavior on their Table Module or Active Record platform that rules with an iron first over database denormalization. They don't seem to realize the tyranny is precisely why the bugs never go away, why features are so hard to add, why people look at each other momentarily before laughing out loud when someone inquires where to find the documentation, or why it's impossible to provide an accurate estimation of work to a curious PM. Resources won't be allocated appropriately, the team will suffer, the inevitable failure of the project will become apparent, you will cry.
If you're a PM or Lead or Solutions Architect or currently living, "implore" the development team to read this book.
You don't know OOD or BDD until you know RDD, DDD will have a home, and then the path to TDD will become clear.
The single most important question I would ask a job candidate is to explain their sentiments between an approach using DCD or using RDD. If they don't know what you're talking about, you've been warned. They can name every GoF pattern in the book and recite the basics of OOD, but it won't matter if they are not well versed in RDD.
Most recent customer reviews
1. Very Good Text on Object Design,
2. A great first text on OO design,
at which situration, according to which...Read more