Responsibility-driven design: Difference between revisions

Revision as of 00:23, 26 January 2012

Revision as of 22:54, 1 February 2012

Line 22:

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

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

On this side the candidate's name, its purpose in the application, stereotype roles and anything worthwileworthwhile 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, 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

Line 43:

===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====

Line 58:

====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===

A role is a set of related responsibilities.<ref name="ObjectDesign-page3"/>. They can be implemented as classes and interfaces. Interfaces, however, are the preferred implementation as they increase 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.

====Controller====

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

====Coordinator====

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

====Information Holder====

Information holder know and provide 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=====

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-page164page165">{{harvnb |Wirfs-Brock|McKean|2002| pp=164165 }}</ref><ref name="ObjectDesign-page165page164">{{harvnb |Wirfs-Brock|McKean|2002| pp=165164 }}</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==

Line 106:

===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===

Line 130:

====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>.

=====Advantages=====

Line 145:

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

=====Advantages=====

Line 163:

====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=====

Line 176:

====Preferred Control Style====

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==

Line 185:

==Bibliography==

* [http://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 022 - 06, 1989). OOPSLA '89. ACM Press, New York, NY, 71-75.

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