Responsibilities and Responsibility-Driven Design
A popular way of thinking about the design of software objects and also larger-scale components is in terms of responsibilities, roles, and collaborations.
This is part of a larger approach called responsibility-driven design or RDD
· doing something itself, such as creating an object or doing a calculation
· initiating action in other objects
· controlling and coordinating activities in other objects
· knowing about private encapsulated data
· knowing about related objects
· knowing about things it can derive or calculate
Who should be responsible for creating a new instance of some class?
The creation of objects is one of the most common activities in an object-oriented system. Consequently, it is useful to have a general principle for the assignment of creation responsibilities.
Assign class B the responsibility to create an instance of class A if one of these is true (the more the better):
· B "contains" or compositely aggregates A.
· B records A.
· B closely uses A.
· B has the initializing data for A that will be passed to A when it is created. Thus B is an Expert with respect to creating A.
B is a creator of A objects.
Information Expert (or Expert)
What is a general principle of assigning responsibilities to objects?
Assign a responsibility to the information expert the class that has the information necessary to fulfill the responsibility.
Do we look in the Domain Model or the Design Model to analyze the classes that have the information needed? The Domain Model illustrates conceptual classes of the real-world domain; the Design Model illustrates software classes.
1. If there are relevant classes in the Design Model, look there first.
2. Otherwise, look in the Domain Model, and attempt to use (or expand) its representations to inspire the creation of corresponding design classes.