Object Design: Roles, Responsibilities and Collaborations (Addison-Wesley Object Technologiey Series) [Paperback]

Intellectual communities suffer from the fact such communities have within them a set of strong willed thinkers. Because of this, such communities have rhetoric, material and theories that may contradict each other. For someone trying to "learn" and develop as a practitioner of the "theory", such contradictions become detrimental. I feel the Object Technology community is one such community that exhibits such symptoms, and as a practitioner myself, I have found it difficult at times to "learn the right thing". If you are like me, and read something, change your ways and then read something new which contradicts what you've just learnt, then this book is for you.

Objects are the abstractions in a software design that exist to provide the implementation that supports the requirements of the users. If you think of objects as Behaviour + data (data isnt capitalised), then profoundly this simple change will affect your work and how you think about a design. This book will guide you towards thinking of objects as much more than data/information holders that are dumb and do little. Gently this book will change the way you think about objects, and how you look at situations were you have one large controlling object that uses data from lots of information holding objects (dumb objects). Its not a trivial road you will be travelling on, but when your journey is over, you will probably scoff at the large Controller, break it down and distribute its responsibilities amongst those once dumb information holders. You'll step back and be profoundly amazed at what you've done. This book will change peoples lives.

If you seriously want to become an OO Practitioner, and wish to develop elegant software that literally does have all of the extensibility and reuse factors built in, then this book is seriously for you. Dont be put off by the title, and think that the Roles, Responsibilities and Collaborations aspect is some kind of "method" or freaky way of developing software. This book teaches you the important parts about thinking in Objects that many other books never ever dream of saying.

Think of requirements, think of objects and think about which object will play in an interaction sequence to fullfil these requirements. Will there be a controller for a use case that makes many decisions? Will you decide not to go for this type of collaboration mechanism and instead opt for more intelligent objects working in a neighbourhood of like-minded objects working towards a common goal? Once you've finished this book, you will most probably be designing with the latter design in mind.

As soon as you think of objects and start asking yourself "What data does this object hold" you are on shakey ground. This book will show you why this is so, and how to change your thinking to build responsible objects in your design. It is a foundational piece of work that will always have a place on my bookshelf.

Graph Node
Description: A node in a graph.

Descriptions like this are semantically content-free; they don't tell you anything that the name hasn't already told you. I've read hundreds of descriptions like this, and even written a few. Generally, I try and put a bit more effort into my descriptions, but its always a struggle.

I bought a copy "Object Design: Roles, Resonsibilities, and Collaborations" and tired applying the CRC technique to a small graph-based diagramming tool I was developing. The updated technique for using CRC cards is to introduce an even earlier step in the process in which you write just a class name and its purpose. Here's a description I wrote on one side of an index card:

Graph Node
Purpose: A graph node is primarily a data holder. It defines a rectangle
on a diagram with a label in its center. It notifies its dependants when it
is created, changed or deleted.

What a difference! This actually tells you something about the object in question and, surprisingly, it was easy to write. The secret of its effectiveness is the change of mind state that results when you replace the somewhat vague 'Description' with the much more leading 'Purpose'. This shifts the emphasis from the 'What' to the 'Why' of an object. If someone asks me 'what' a graph node is my knee-jerk response is, "A node in a graph, stupid!" but when I'm asked what its purpose is a host of details come pouring out.

Now I'm a convert. If I'm using a case tool now I write 'purpose-full' object descriptions, and I find it works with attributes and relationships too. If I'm writing C++ by hand, I put a 'Purpose:' section at the top of the header file and fill it in.

"Object Design..." has a lot more to say about the early phases of modeling and I can heartily recommend it to those who want to improve their transition from object blitz to production code.

The book presents the responsibility-driven approch, where you design objects by thinking in terms of roles, responsibilities, and collaborations. The responsibility-driven approch has been introduced by the authors in the nineties and applied and improved in the last decade. It is really a modern and current approach!

Object-oriented design is described according to various perspectives that must be considered during design: object identification, responsibility identification and assignment according, collaborations, control style, and so on. For carrying out each task, several possible alternatives are described and compared -- as it should happen in real software development. In general, the book is plently of advices based upon the authors' experience in designing REAL object applications.

The method proposed is fully compatible with current standards and tools (e.g., use cases, UML and the Unified Process). Still, the book does not constraint itself to none of those standards - the proposed approach has a very wide applicability wrt existing methods and processes.

Also, it references a number of very good books related to object-oriented software development.

However, this is not an introductory book on object design. If you are new to this topic, you better read first an introduction to object methods. Personally, I recommend "Applying UML and Patterns" (2nd edition) by Craig Larman, a very good introduction to object-oriented analysis and design. Then, the book by Wirfs-Brock and McKean will let you complete your vision and understanding of the beautiful - but difficult - realm of object-oriented design. Enjoy it!