Responsibility-driven design: Difference between revisions

Revision as of 00:23, 26 January 2012

Latest revision as of 12:57, 10 January 2025

(40 intermediate revisions by 25 users not shown)

Line 1:

{{short description|Design technique in object-oriented programming}}

'''Responsibility-driven design''' is a design technique in [[Object-oriented programming]]. It was proposed by [[Rebecca Wirfs-Brock]] and Brian Wilkerson who defined it as follows:

{{Redirects here|Data-driven design|the optimization approach|Data-oriented design}}

<blockquote>

{{primary sources|date=December 2012}}

Responsibility-driven design is inspired by the client/server model. It focuses on the contract by asking:

'''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 (computer science)|object]] is responsible for and the information that the object shares. It was proposed by [[Rebecca Wirfs-Brock]] and Brian Wilkerson.

* What actions is this object responsible for?

* What information does this object share?

</blockquote>

Responsibility-driven design is in direct contrast with Datadata-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 [[Datadata-driven programming]], which is concerned with using data to determine the [[control flow]], not class design.

TheIn the [[client/serverclient–server model]] model they refer to, assumesboth that a softwarethe client and a softwarethe server exchangeare information[[Class based(computer onprogramming)|classes]] aor contract[[Instance that(computer bothscience)|instances]] of classes. At any particular time, either the client or the server represents an object. Both the parties commit to adherea [[contract]] and exchange information by adhering to it. The client maycan only make the requests specified, in the contract and the server must answer themthese requests.<ref name="Wirfs-Brock1989">{{cite journal|last1=Wirfs-Brock|first1=Rebecca|last2=Wilkerson|first2=Brian|title=Object-Oriented Design: A Responsibility-Driven Approach|journal=ACM SIGPLAN Notices|date=1989|volume=24|issue=10|page=74|doi=10.1145/74878.74885|doi-access=free}}</ref> 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 (computer programming)|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 functionfunctions should be finely grained, such as in [[Eiffel (programming language)|Eiffel]] programming language. Even finer control of the visibility of even classes is available in the [[Newspeak (programming language)|Newspeak]] programming language.

==Overview==

==Building Blocks of RDD==

Responsibility-driven design focuses on the objects as [https://www.cs.cmu.edu/~rbd/doc/nyquist/part4.html behavioral abstractions] which are characterized by their responsibilities. The [[Class-responsibility-collaboration card|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.<ref name="AnthonySimons">{{cite book | chapter=Design Patterns as Litmus Paper to Test the Strength of Object-Oriented Methods | year=1998 | chapter-url=http://citeweb.info/19980495062 | doi=10.1007/978-1-4471-0895-5_10 | author1=Anthony J. H. Simons | title=Oois'98 | pages=129–147 | author2=Monique Snoeck | author3=Kitty Hung| isbn=978-1-85233-046-0 | citeseerx=10.1.1.130.8713 }}</ref> This makes the design follow type hierarchy for inheritance which improves encapsulation and makes it easier to identify [[abstract class]]es. It can also group the classes together based on their clients which is considered a unique ability.

In their book Object Design: Roles, Responsibilities and Collaborations<ref name="ObjectDesign-entirebook">{{harvnb |Wirfs-Brock|McKean|2002 }}</ref> the authors describe the following building blocks that make up Responsibility-Driven Design.

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 [http://www.computerhope.com/jargon/d/distribs.htm distributed systems]. Similarly, it can help to design and maintain explanation facilities for [[cognitive model]]s, [[intelligent agent]]s, and other [[knowledge-based systems]].<ref name="Cognitive Models">{{cite web | title=Responsibility-Driven Explanation Engineering for Cognitive Models | year=2004 | url=http://citeweb.info/20040821547 | author1=Steven R. Haynes | author2=Isaac G. Councill | author3=Frank E. Ritter}}</ref>

===Application===

A software application is referred to as a set of interacting objects<ref name="ObjectDesign-page3"/>

===Candidates=Building blocks==

In their book ''Object Design: Roles, Responsibilities and Collaborations'',<ref name="ObjectDesign-entirebook">{{cite book|author1=Wirfs-Brock, Rebecca|author2=McKean, Alan|title=Object Design: Roles, Responsibilities, and Collaborations|date=2003|publisher=Addison-Wesley|___location=Indianapolis, IN|isbn=978-0201379433|ref=odrrc}}</ref> the authors describe the following building blocks that make up responsibility-driven design.

Candidates or candidate objects are key concepts in the form of objects described on CRC cards. They serve as initial inventions in the process of object design.<ref name="ObjectDesign-page58">{{harvnb |Wirfs-Brock|McKean|2002| pp=58 }}</ref>

* Application: A software application is referred to as a set of interacting objects.<ref name="ObjectDesign-page3"/>

===Collaborations===

* Candidates: Candidates or candidate objects are key concepts in the form of objects described on CRC cards. They serve as initial inventions in the process of object design.<ref name="ObjectDesign-page58">{{harvnb |Wirfs-Brock|McKean|2002| pp=58 }}</ref>

A collaboration is defined as an interaction of objects or roles (or both)<ref name="ObjectDesign-page3"/>.

* Collaborations: A collaboration is defined as an interaction of objects or roles (or both).<ref name="ObjectDesign-page3"/>

* CRC Cards: CRC stands for Candidates, Responsibilities, Collaborators. They are index cards used in early design for recording candidates.<ref name="ObjectDesign-page61">{{harvnb |Wirfs-Brock|McKean|2002| pp=61 }}</ref> These cards are split up into an unlined and a lined side.

** Content of lined side: On this side the candidate's name, its responsibilities and its collaborators are recorded.<ref name="ObjectDesign-page61"/>

** Content of unlined side: On this side the candidate's name, its purpose in the application, stereotype roles and anything worthwhile such as the names of roles in patterns it participates in are recorded.<ref name="ObjectDesign-page61"/>

* Hot Spots: Hot Spots are points in the application where variations occur. They are recorded using Hot Spot Cards.<ref name="ObjectDesign-page72">{{harvnb |Wirfs-Brock|McKean|2002| pp=72 }}</ref>

* Hot Spot Cards: Hot Spot Cards are used for recording variations with just enough detail so you can discriminate important difference. Similar to CRC cards, these are also created from [[index card]]s.<ref name="ObjectDesign-page72"/> These cards consist of:

** Hot Spot Name

** General description of the variation

** At least two specific examples where the variation occurs

===CRC CardsObjects===

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.<ref name="ObjectDesign-page3"/>

CRC stands for Candidates, Responsibilities, Collaborators. They are index cards used in early design for recording candidates<ref name="ObjectDesign-page61">{{harvnb |Wirfs-Brock|McKean|2002| pp=61 }}</ref>. These cards are split up into an unlined and a lined side.

* Object Neighborhoods: Another term for subsystem.<ref name="ObjectDesign-page17">{{harvnb |Wirfs-Brock|McKean|2002| pp=17 }}</ref> It is a logical grouping of collaborators.<ref name="ObjectDesign-page17"/>

====Content of lined side====

On* thisResponsibilities: sideA theresponsibility candidate'sis name,an itsobligation responsibilitiesto andperform itsa collaboratorstask areor know recordedinformation.<ref name="ObjectDesign-page61page3">{{harvnb |Wirfs-Brock|McKean|2002| pp=613 }}</ref> These are further categorized according to their usage scenario.

** Public Responsibilities: Public responsibilities are the responsibilities an object offers as services to others and the information it provides to others.<ref name="ObjectDesign-page126">{{harvnb |Wirfs-Brock|McKean|2002| pp=126 }}</ref>

** Private Responsibilities: Private responsibilities are the actions an object takes in support of public responsibilities.<ref name="ObjectDesign-page126"/>

====Content of unlined side====

** Subresponsibilities: Sometimes, a large or complicated responsibility is split up into smaller ones called subresponsibilities.<ref name="ObjectDesign-page168">{{harvnb |Wirfs-Brock|McKean|2002| pp=168 }}</ref> They are further categorized based on what they do.

On this side the candidate's name, its purpose in the application, stereotype roles and anything worthwile such as the names of roles in patterns it participates in are recorded<ref name="ObjectDesign-page61"/>.

*** Subordinate Responsibilities: These include the major steps in each subresponsibility.<ref name="ObjectDesign-page168"/>

*** Sequencing Responsibilities: These refer to the sequencing of the execution of subordinate responsibilities.<ref name="ObjectDesign-page168"/>

===Hot Spots===

Hot Spots are points in the application where variations occur. They are recorded using Hot Spot Cards<ref name="ObjectDesign-page72">{{harvnb |Wirfs-Brock|McKean|2002| pp=72 }}</ref>.

===Hot Spot Cards===

Hot Spot Cards are used for recording variations, so called hot spots. They are similarly to CRC cards low-level tools in the form of index cards<ref name="ObjectDesign-page72">{{harvnb |Wirfs-Brock|McKean|2002| pp=72 }}</ref>. These cards consist of:

* Hot Spot Name

* General description of the variation

* At least two specific examples where the variation occurs

===Objects===

Objects are described as things that have machinelike behaviors that can be plugged together to work in concert. These objects play well-defined roles and encapsulate scripted responses and information<ref name="ObjectDesign-page3"/>.

===Object Neighborhoods===

Another term for subsystem<ref name="ObjectDesign-page17">{{harvnb |Wirfs-Brock|McKean|2002| pp=17 }}</ref>. It is a logical grouping of collaborators<ref name="ObjectDesign-page17"/>.

===Responsibilities===

A responsibility is an obligation to perform a task or know information<ref name="ObjectDesign-page3">{{harvnb |Wirfs-Brock|McKean|2002| pp=3 }}</ref>. These are further categorized according to their usage scenario.

====Public Responsibilities====

Public responsibilities are the responsibilities an object offers as services to others and the information it provides to others<ref name="ObjectDesign-page126">{{harvnb |Wirfs-Brock|McKean|2002| pp=126 }}</ref>.

====Private Responsibilities====

Private responsibilities are the actions an object takes in support of public responsibilities<ref name="ObjectDesign-page126"/>

====Subresponsibilities====

These responsibilities come into existence whenever a large or complicated responsibility is split up into smaller ones<ref name="ObjectDesign-page168">{{harvnb |Wirfs-Brock|McKean|2002| pp=168 }}</ref>. They are further categorized by what they do.

=====Subordinate Responsibilities=====

These are the major steps of the subresponsibility<ref name="ObjectDesign-page168"/>.

=====Sequencing Responsibility=====

This responsibility refers to the sequencing of the execution of subordinate responsibilities<ref name="ObjectDesign-page168"/>.

===Roles===

AObject role refers to an exterior view of what general service is offered by the object. It is a set of related responsibilities.<ref name="ObjectDesign-page3"/>. TheyIt can be implemented as classesa class or andan interfacesinterface. InterfacesInterface, however, areis the preferred implementation as theyit increaseincreases flexibility by hiding the concrete class which ultimately does the work.<ref name="ObjectDesign-page340">{{harvnb |Wirfs-Brock|McKean|2002| pp=340 }}</ref>.

Role Stereotypes: Role stereotypes are simplified roles that come with predefined responsibilities.<ref name="ObjectDesign-page4">{{harvnb |Wirfs-Brock|McKean|2002| pp=4 }}</ref> There are several categories.

===Role Stereotypes===

* Controller: Object implementing this role makes decisions and closely directs the action of other objects.<ref name="ObjectDesign-page4"/>

Role stereotypes are simplified roles that come with predefined responsibilities<ref name="ObjectDesign-page4">{{harvnb |Wirfs-Brock|McKean|2002| pp=4 }}</ref>. There are several categories.

* Coordinator: This role reacts to events by delegating tasks to others.<ref name="ObjectDesign-page4"/>

* Information Holder: Information holder knows and provides information.<ref name="ObjectDesign-page4"/>

** Information Provider: A slight variation of an information holder is the information provider, which takes a more active role in managing and maintaining information. This distinction can be used if a designer needs to get more specific.<ref name="ObjectDesign-page93">{{harvnb |Wirfs-Brock|McKean|2002| pp=93 }}</ref>

* Interfacer: This role transforms information and requests between distinct parts of an application.<ref name="ObjectDesign-page4"/> It is further divided into more specific roles.

** External Interfacer: External interfacer communicates with other applications rather than its own.<ref name="ObjectDesign-page93"/> It is mainly used for encapsulating non-object-oriented APIs and does not collaborate a lot.<ref name="ObjectDesign-page165"/>

** Internal Interfacer: Also called intersystem interfacer.<ref name="ObjectDesign-page93"/> It act as a bridge between object neighborhoods.<ref name="ObjectDesign-page165"/>

** User Interfacer: User interfacer communicates with users by responding to events generated in the UI and then passing them on to more appropriate objects.<ref name="ObjectDesign-page93"/><ref name="ObjectDesign-page165">{{harvnb |Wirfs-Brock|McKean|2002| pp=165 }}</ref><ref name="ObjectDesign-page164">{{harvnb |Wirfs-Brock|McKean|2002| pp=164 }}</ref>

* Service Provider: This role performs work and offers computing services.<ref name="ObjectDesign-page93"/>

* Structurer: This role maintains relationships between objects and information about those relationships.<ref name="ObjectDesign-page93"/>

====Controller==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 [https://en.wiktionary.org/wiki/sub-system subsystems].

Objects implementing this role make decisions and closely direct the action of other objects<ref name="ObjectDesign-page4"/>.

* Concept of Control : The responsibilities and collaborations among the classes.<ref name="Evaluating the effect of a delegated versus centralized control style on the maintainability of object-oriented software">{{cite journal|first1=Arisholm|last1 = Eric|first2 = Sjoberg|last2 =Dag I.K.|title=Evaluating the effect of a delegated versus centralized control style on the maintainability of object-oriented software|journal = IEEE Transactions on Software Engineering|date=2004|volume=30|issue=8|pages = 521–534|doi = 10.1109/TSE.2004.43|s2cid = 6396127}}</ref>

====Coordinator====

* Control Centers : An important aspect of developing a control style is the invention of so-called control centers. These are places where objects charged with controlling and coordinating reside.<ref name="ObjectDesign-page196">{{harvnb |Wirfs-Brock|McKean|2002| pp=196 }}</ref>

This role reacts to events by delegating tasks to others<ref name="ObjectDesign-page4"/>.

* Control Style Variations : A control style comes in three distinct variations. These are not precise definitions though since a control style can be said to be more centralized or delegated than another.

=== Centralized control style ===

====Information Holder====

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.

Information holder know and provide information <ref name="ObjectDesign-page4"/>.

;Types

=====Information Provider=====

* Call-return model : The control of the objects in the application is in hierarchical way. Control starts at root and moves downwards. It is used in a sequential model.

A slight variation of an information holder is the information provider, which takes a more active role in managing and maintaining information. This distinction can be used if a designer needs to get more specific<ref name="ObjectDesign-page93">{{harvnb |Wirfs-Brock|McKean|2002| pp=93 }}</ref>.

* Manager model : The control of the objects in the application is in with only one object. Generally, it is implemented in concurrent models. It can also be implemented in sequential model using [[Switch statement|case statement]].

;Advantages

====Interfacer====

* Application logic is in one place.

This role transforms information and requests between distinct parts of an application<ref name="ObjectDesign-page4"/>. It is further divided into more specific roles.

;Disadvantages

=====External Interfacer=====

These interfacers communicate with other applications than your own.<ref name="ObjectDesign-page93"/>. They are mainly used for encapsulating non-object-oriented APIs and do not collaborate a lot.<ref name="ObjectDesign-page165"/>.

=====Internal Interfacer=====

Also called intersystem interfacers<ref name="ObjectDesign-page93"/>. These interfacers act as a bridge between object neighborhoods<ref name="ObjectDesign-page165"/>.

=====User Interfacer=====

These interfacers communicate with users by responding to events generated in the UI and then passing them on to more appropriate objects. <ref name="ObjectDesign-page93"/><ref name="ObjectDesign-page164">{{harvnb |Wirfs-Brock|McKean|2002| pp=164 }}</ref><ref name="ObjectDesign-page165">{{harvnb |Wirfs-Brock|McKean|2002| pp=165 }}</ref>

====Service Provider====

This role performs work and offers computing services<ref name="ObjectDesign-page93"/>.

====Structurer====

This role maintains relationships between objects and information about those relationships<ref name="ObjectDesign-page93"/>.

==Control Style==

An important part in the Responsibility-Driven Design process is the distribution of control responsibilities that results in developing a control style.

===Concept of Control===

Control styles relie heavily on the concept of Control. Therefore it makes sense to properly define the term. It is defined as decision making and selection of paths through an application<ref name="ObjectDesign-page155">{{harvnb |Wirfs-Brock|McKean|2002| pp=155 }}</ref>.

===Control Centers===

An important aspect of developing a control style is the invention of so called control centers. These are places where objects charged with controlling and coordinating reside.<ref name="ObjectDesign-page196">{{harvnb |Wirfs-Brock|McKean|2002| pp=196 }}</ref>.

===Control Style Variations===

A control style comes in three distinct variations. These are not precise definitions though since a control style can be said to be more centralized or delegated than another.

====Centralized Control Style====

This control style inflicts a procedural paradigma on the structure of the application and places major-decision making responsibilities in only a few objects.

=====Advantages=====

* Application-logic is in one place.

=====Disadvantages=====

* Control logic can get overly complex

* Controllers can become dependent on information holders' contents

Line 126 ⟶ 79:

* The only interesting work is done in the controller

=====;When to use=====

When decisions to be made are few, simple, and related to a single task.

====ClusteredDelegated Controlcontrol Style=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.

This control style is a variation of the centralized control style wherein control is factored among a group of objects whose actions are coordinated<ref name="ObjectDesign-page197">{{harvnb |Wirfs-Brock|McKean|2002| pp=197 }}</ref>. 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<ref name="ObjectDesign-page213">{{harvnb |Wirfs-Brock|McKean|2002| pp=213 }}</ref>.

;Types[reference]

=====Advantages=====

* Broadcast model : An event is broadcast to all objects in the application. The object which can handle the event can acquire the control.

* Application-logic is in one place.

* Interrupt-driven model : There will be the [[interrupt]] handler to process the interrupt and passes to some object to process it.

;Advantages

=====Disadvantages=====

* It is easy to understand.

* Control logic can get overly complex

* Though there is an external coordinator, Objects can be made smarter to know what they are supposed to do and can be reused in other applications.

* Controllers can become dependent on information holders' contents

* Delegating coordinators tend to know about fewer objects than dominating controllers.

* Objects can become coupled indirectly through the actions of their controller

* Dialogs are higher-level.

* The only interesting work is done in the controller

* It is easy to change as changes typically affect fewer objects.

* It is easier to divide design work among team members.

;Disadvantages

=====When to use=====

* Too much distribution of responsibility can lead to weak objects and weak collaborations

When decisions to be made are few, simple, and related to a single task.

;When to use

====Delegated Control Style====

When one wants to delegate work to objects that are more specialized.

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 signifcant role to play.

=====Advantages==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.<ref name="ObjectDesign-page197">{{harvnb |Wirfs-Brock|McKean|2002| pp=197 }}</ref> 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.<ref name="ObjectDesign-page213">{{harvnb |Wirfs-Brock|McKean|2002| pp=213 }}</ref>

* It is easy to find out how something works since only few objects are involved<ref name="ObjectDesign-page32">{{harvnb |Wirfs-Brock|McKean|2002| pp=32 }}</ref>

* It is reusable because each object is largely capable of fulfilling its own responsibilities<ref name="ObjectDesign-page32"/>

* System functions can be used in relative isolation since they are organized into pools of responsibilities<ref name="ObjectDesign-page32"/>

* Delegating coordinators tend to know about fewer objects than dominating controllers

* Dialogs are higher-level

* Changes typically affect fewer objects

* It is easier to divide design worka mong team members

=====Disadvantages==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.<ref name="ObjectDesign-page30">{{harvnb |Wirfs-Brock|McKean|2002| pp=30 }}</ref>

* Too much distribution of responsibility can lead to weak objects and weak collaborations

=====When to use=====

When you want to delegate work to objects that are more specialized.

====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<ref name="ObjectDesign-page30">{{harvnb |Wirfs-Brock|McKean|2002| pp=30 }}</ref>.

=====;Advantages=====

* None

=====;Disadvantages=====

* When you want to find out how something works, you must trace the sequence of requests for services across many objects

* Not very reusable because no single object contributes much

=====;When to use=====

Never.

====Preferred Controlcontrol Style=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.<ref name="Evaluating the effect of a delegated versus centralized control style on the maintainability of object-oriented software"/>

The inventors of Responsibility-Driven Design recommend using a delegated control style because no one object knows or does too much<ref name="ObjectDesign-page133">{{harvnb |Wirfs-Brock|McKean|2002| pp=133 }}</ref>.

==Conflict with the law of Demeter==

According to Wirfs-Brock and Wilkerson, there's a conflict between the [[Law of Demeter]] and Responsibility-driven design. The law of Demeter says that messages can be sent only to the following: message argument, instance variable, new objects, global variables. Therefore, sending a message to the result of a previous message send isn't allowed. However, "returned values are part of the client/server contract. There need be no correlation between the structure of an object and the object returned by the message."

==References==

Line 185 ⟶ 126:

==Bibliography==

* [httphttps://dx.doi.org/10.1145/74877.74885 Object-oriented design: a responsibility-driven approach]. In Conference Proceedings on Object-Oriented Programming Systems, Languages and Applications (New Orleans, Louisiana, United States, October 02 - 062–06, 1989). OOPSLA '89. ACM Press, New York, NY, 71-75.

* {{cite book |authorauthor1=Wirfs-Brock, Rebecca; |author2=McKean, Alan |title= [[Object Design: Roles, Responsibilities, and Collaborations]] |publisher= [[Addison Wesley]] |yeardate=November 2002 |month= November |isbn= 978-0-201-37943-03 |ref=CITEREFWirfs-BrockMcKean2002 }}

[[Category:Object-oriented programming]]