Object Design: Roles, Responsibilities, and Collaborations

Share

Object Design: Roles, Responsibilities, and Collaborations
| 2002-11-08 00:00:00 | | 0 | Software Engineering


After more than ten years, object technology pioneer Rebecca Wirfs-Brock teams with expert Alan McKean to present a thoroughly updated, modern, and proven method for the design of software. The book is packed with practical design techniques that enable the practitioner to get the job done. Like many human endeavors, design is part art, part engineering, part guesswork, and part experimentation. Discipline, hard work, inspiration, and sound technique all play their part as well. For any given problem, there are many reasonable, but only a few very good solutions. The authors' goal is to help readers learn to make those very good design decisions on their own. The book explores challenges that software developers will face as they build their design, and shows how design patterns can be used to solve design problems. Long awaited and eagerly anticipated, this book represents the first great software design book of the century. A FUTURE CLASSIC!

User review
Very Good Text on Object Design, A great first text on OO design, Total Disappointment for experienced Programmers
I have to agree with some earlier reviews on this book.

1. Very Good Text on Object Design,

2. A great first text on OO design,

3. Total Disappointment for Programmers


This is a great book on Object Oriented Design, but ONLY for novice and intermediate object modelers. It is not for an experienced developer who already knows how to use some of the design patterns in Gang of Four book.


If we use an analogy to compare this two books, if Gang of Four Design Pattern book is for post graduate students, Object Design is for the student in the second year of the university.


I want to read more on Object Oriented development so I started to read this book, mainly attracted by its cover. Domain Driven Design by Eric Avans falls into the same category but offers much more exercise for your brain.


Hope this is helpful. I have 10+ years in software development, 7+ years in Java, understand OO and Domain Driven Design.


5 Star Book for a beginner.

User review
Hit and Misses
The authors provides a good introduction to object oriented analysis and design. Some may find that the content is too wishy washy with seemingly vague advice in many areas. The responsibility driven approach along with object stereotypes are indeed a good way to approach OO design however. The concept of object neighborhood and control style are also worthy of praise.


If the reader persists they'll be rewarded with a good understanding of why OO design is needed. There are nuggets of wisdom throughout the book, however many sections seem to be hastily done and glossed over. Too many times the authors resort to bullet listings to explain concepts. That may be acceptable in today's power point age but its not acceptable for a technical book. Reading lists after lists of advice is not a good way to learn and retain concepts.

User review
Developer, Programmer, and System Modeler
I have read so many OOAD books, none of which give me a clear idea how and why software design should be designed that way,

at which situration, according to which external facts should the correct design decision be selected and considered.

In core OO design stream, we will distributed/assigned each object with their desirable responsibilities, we must select a flexible control and coordation style to allow software for change. it is a system view of our software.


This book given me a best introduction to think a solution all above questions and design views(system behavours).

When I read and studies this book, it let me consolid and remenber many knowledge above control theory, layer architecture of big software system such as CAD system.


Each project have particular siturations and design constraints,

how we can design a useful software to solve user requirements is the first thing to consider.


Many formal formalism will not be work for flexiblity, such as RUP CMMI,,. etc, those processes like a doing documentation not a useful design and devlivery working software that fit our users requests. I think experience programmer, developer should more thinking in system point of view.



User review
Total Disappointment for Programmers
I am a developer/programmer for a technical software company and my review contains my perception of this book from that perspective. I must also disclose that I am sceptical of any object-oriented design methodology that involves a lot of writing. We are `programmers`, not story writers (read use cases).


When I ordered this book a week ago, I couldn't wait to get my hands on this book because it sounded so promising. My enthusiasm turned into total disappointment so quickly I couldn't believe myself; I had to give another shot in reading this book to make sure. But I am convinced; the authors managed the impossible task of filling its 390 pages without saying anything substantial about object-oriented design for a professional software developer.


The book might be useful for a novice programmer or a manager in terms of defining the object design jargon and process. But other than this, it provides no valuable advice for a professional. These are some of the points that I find ridiculously simplistic and almost idiotic:


- In my opinion use cases and CRC cards all boil down to writing on a piece of paper what classes one should use and what these classes should do. This is not methodology, it is common sense. Any sensible developer would write down his/her ideas about the classes involved in an application before starting to program.


- Although it is valuable advice to think about class responsibilities, the book states nothing more than the obvious in terms of finding what responsibilities should be assigned to which classes. Statements like `Responsibilities come from statements or implications of system behavior found in use cases` are tautologies. Where else would they come from!


- Or the chapter on Flexibility says things like `Find out what you don't know`. I can't even begin to elaborate on philosophical implications of such advice!


Although the book looks appealing to the eye, it has no clear content. It states ideas about classes, responsibilities, etc without a clear structure; and after a while, everything said seems to be a repetition of some earlier statements.


If you are serious about object-oriented design as a `programmer` I recommend these three books:


1. Gamma E., et al., Design Patterns.

2. James R Rumbaugh, et al., Object-Oriented Modeling and Design. A bit dated, but you will get all you need to know about object oriented design from this book.

3. Bjarne Stroustrup, The C++ Programming Language (Special 3rd Edition). Never mind it is a C++ book. Chapters on OOD (I think chapters 21-25) will tell you exactly what you need to understand to start programming using OO approach.


Do yourself a favor and invest in these books; and ignore all the fab about such trendy books such as the one reviewed above.



User review
OO-Collaborations Perspective
Overall very good impression, original presentation with sidebar essential quotes. However after a while seems more of the same: how to identify collaborations in an Object Oriented Design. Special note for Chapter 8, where valuable and interesting information is provided regarding exceptions and errors.