Responsibility-driven design

Responsibility-driven design is a design technique in object-oriented programming, which improves encapsulation by using the client–server model. It focuses on the contract by considering the actions that the object is responsible for and the information that the object shares. It was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.
Responsibility-driven design is in direct contrast with data-driven design, which promotes defining the behavior of a class along with the data that it holds. Data-driven design is not the same as data-driven programming, which is concerned with using data to determine the control flow, not class design.
In the client–server model they refer to, both the client and the server are classes or instances of classes. At any particular time, either the client or the server represents an object. Both the parties commit to a contract and exchange information by adhering to it. The client can only make the requests specified in the contract and the server must answer these requests. Thus, responsibility-driven design tries to avoid dealing with details, such as the way in which requests are carried out, by instead only specifying the intent of a certain request. The benefit is increased encapsulation, since the specification of the exact way in which a request is carried out is private to the server.
To further the encapsulation of the server, Wirfs-Brock and Wilkerson call for language features that limit outside influence to the behavior of a class. They demand that the visibility of members and functions should be finely grained, such as in Eiffel programming language. Even finer control of the visibility of even classes is available in the Newspeak programming language.
Overview.
Responsibility-driven design focuses on the objects as behavioral abstractions which are characterized by their responsibilities. The CRC-card modelling technique is used to generate these behavioral abstractions. The rest of the object structure including data attributes are assigned later, as and when required. This makes the design follow type hierarchy for inheritance which improves encapsulation and makes it easier to identify abstract classes. It can also group the classes together based on their clients which is considered a unique ability.
A good object-oriented design involves an early focus on behaviors to realize the capabilities meeting the stated requirements and a late binding of implementation details to the requirements. This approach especially helps to decentralize control and distribute system behavior which can help manage the complexities of high-functionality large or distributed systems. Similarly, it can help to design and maintain explanation facilities for cognitive models, intelligent agents, and other knowledge-based systems.
Building blocks.
In their book "Object Design: Roles, Responsibilities and Collaborations", the authors describe the following building blocks that make up responsibility-driven design.
Objects.
Objects are described as things that have machine-like behaviors that can be plugged together to work in concert. These objects play well-defined roles and encapsulate scripted responses and information.
Roles.
Object role refers to an exterior view of what general service is offered by the object. It is a set of related responsibilities. It can be implemented as a class or an interface. Interface, however, is the preferred implementation as it increases flexibility by hiding the concrete class which ultimately does the work.
Role Stereotypes: Role stereotypes are simplified roles that come with predefined responsibilities. There are several categories.
Control style.
An important part in the responsibility-driven design process is the distribution of control responsibilities that results in developing a control style. A control style is concerned about the control flow between subsystems.
Centralized control style.
This control style inflicts a procedural paradigm on the structure of the application and places major-decision making responsibilities in only a few objects or a single object.
When decisions to be made are few, simple, and related to a single task.
Delegated control style.
A delegated control style lies in between a centralized and dispersed control style. It passes some of the decision making and much of the action to objects surrounding a control center. Each neighboring object has a significant role to play. It can also be called as event driven model, where the control is delegated to the object requesting it to process the event.
When one wants to delegate work to objects that are more specialized.
Clustered control style.
This control style is a variation of the centralized control style wherein control is factored among a group of objects whose actions are coordinated. The main difference between a clustered and delegated control style is that in a clustered control style, the decision making objects are located within a control center whereas in a delegated control style they are mostly outside.
Dispersed control style.
A dispersed control style does not contain any control centers. The logic is spread across the entire population of objects, keeping each object small and building in as few dependencies among them as possible.
Never.
Preferred control style.
After extensive results of experiments conducted, only the senior management has the necessary skills to make use of delegated control style and centralized control style benefits programmers. There is no context mentioned about the mid-level employees.