Book: Object Design: Roles, Responsibilities, and Collaborations
- Responsibility-Driven Design: Objects are not just simple bundles of logic and data. They are responsible members of an object community.
For any given problem there are many reasonable solutions, and a few very good solutions.
- vocabulary for describing your design
- strategies for finding objects
- recipes for developing a collaborative model
- framework for discussing design trade-offs
Dynamic behavior of a software system emerges from the interactions of many objects—each contributing, each playing a responsible role.
Our measure of success lies in how clearly we invent a software reality that satisfies our application’s requirements—and not in how closely it resembles the real world.
| An application | a set of interacting objects |
| An object | an implementation of one or more roles |
| A role | a set of related responsibilities |
| A responsibility | an obligation to perform a task or know information |
| A collaboration | an interaction of objects or roles (or both) |
| A contract | an agreement outlining the terms of a collaboration |
A role is a set of responsibilities that can be used interchangeably.
Object Role Stereotypes
- Information holder knows and provides information
- Structurer maintains relationships between objects and information about those relationships
- Service provider performs work and, in general, offers computing services
- Coordinator reacts to events by delegating tasks to others
- Controller makes decisions and closely directs others’ actions
- Interfacer transforms information and requests between distinct parts of our system
Some objects are hard to stereotype because they seem to fit into more than one category
Clearly defined objects that stick to the point when implementing their roles are easier to understand and maintain.