ResponsibilityDrivenDesign
From Epowiki
Responsibility Driven Design
Responsibility-Driven Design, catalyzes object technology with techniques that help you reason about the organization and roles in a well-designed object model. CrcCards are way of generating designs based on responsibilities.
In a responsibility-based model, objects play specific roles and occupy well-known positions in the application architecture. It is a smoothly-running community of objects. Each object is accountable for a specific portion of the work. They collaborate in clearly-defined ways, contracting with each other to fulfill the larger goals of the application. By creating such a "community of objects," assigning specific responsibilities to each, we build a collaborative model of our application.
Objects are more than simple bundles of logic and data ... they are service-providers, information-holders, structurers, coordinators, controllers, and interfacers to the outside world! Each must know and do its part! Thinking in these terms enables you to build powerful, flexible applications. Other design methods tend to focus on logic and data alone. They leave out the big picture and miss the point of objects. Responsibility-Driven Design, on the other hand, offers practical advice for designing, implementing and redesigning responsibilities.
Responsibility-Driven Design enables you think clearly about object design and to leverage object technology to its full advantage.
"Understanding responsibilities is key to good object-oriented design" - Martin Fowler, noted object expert and author of UML Distilled
The shift from thinking about objects as data + algorithms, to thinking about objects as roles + responsibilities can be a profound one. It impacts all development activities. During analysis, we think about what the system is responsible for. We map system responsibilities to appropriate object roles and responsibilities during design. We use responsibilities to define the interfaces of our classes and their test plans during coding. Programmers still reason about and discuss object responsibilities while they cope with myriad coding details. When details are hidden in "helper" code they can be changed and extended swiftly without affecting the implementation of major responsibilities. In a complex world of code and data structures, object responsibilities marry the way we think about our applications to its invisible world of executable code.
