A popular way of thinking about the design of software objects and also larger-scale componentsresponsibilities, roles, and collaborations. This is part of a larger approach called responsibility-driven design or RDD [WM02]. [3] Thinking in terms of responsibilities can apply at any scale of softwarefrom a small object to a system of systems. In RDD, we think of software objects as having responsibilitiesan abstraction of what they do. The UML defines a responsibility as "a contract or obligation of a classifier" [OMG03b]. Responsibilities are related to the obligations or behavior of an object in terms of its role. Basically, these responsibilities are of the following two types: doing and Doing responsibilities of an object include: 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 responsibilities of an object include: knowing about private encapsulated data knowing about related objects knowing about things it can derive or calculate Responsibilities are assigned to classes of objects during object design. For example, I may declare that "a Sale is responsible for creating SalesLineItems " (a doing), or "a Sale is responsible for knowing its total" (a knowing). Guideline :
For software domain objects, the domain model, because of the attributes and associations it illustrates, often inspires the relevant responsibilities related to "knowing." For example, if the domain model Sale class has a time attribute, it's natural by the goal of low representational gap that a software Sale class knows its time. low representational gap p. 138 The translation of responsibilities into classes and methods is influenced by the granularity of the responsibility. Big responsibilities take hundreds of classes and methods. Little responsibilities might take one method. For example, the responsibility to "provide access to relational databases" may involve two hundred classes and thousands of methods, packaged in a subsystem. By contrast, the responsibility to "create a Sale " may involve only one method in one class. A responsibility is not the same thing as a methodit's an abstractionbut methods fulfill responsibilities. RDD also includes the idea of collaboration. Responsibilities are implemented by means of methods that either act alone or collaborate with other methods and objects. For example, the Sale class might define one or more methods to know its total; say, a method named getTotal . To fulfill that responsibility, the Sale may collaborate with other objects, such as sending a getSubtotal message to each SalesLineItem object asking for its subtotal. RDD is a Metaphor
RDD is a general metaphor for thinking about OO software design. Think of software objects as similar to people with responsibilities who collaborate with other people to get work done. RDD leads to viewing an OO design as a community of collaborating responsible objects . Key point :
GRASP names and describes some basic principles to assign responsibilities, so it's useful to knowto support RDD.