Responsibility-driven design: Difference between revisions

Revision as of 16:03, 5 June 2016

Revision as of 21:03, 9 February 2017

Line 55:

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

* 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"|date=2004|volume=30|issue=8|url=http://ieeexplore.ieee.org/document/1316869/citations}}</ref>.

* Concept of Control : Control styles rely 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 paradigm on the structure of the application and places major-decision making responsibilities in only a few objects or a single object.

;Types

;Advantages

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

* Application logic is in one place.

* 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]].

;Disadvantages

* Control logic can get overly complex

* Controllers can become dependent on information holders' contents

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

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

===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 92 ⟶ 81:

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

;Types[reference]

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

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

;Advantages

* It is easy to understand.

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

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

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

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

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

* Dialogs are higher-level.

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

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

* Dialogs are higher-level

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

* Changes typically affect fewer objects

* It is easier to divide design work among team members

;Disadvantages

Line 108 ⟶ 100:

;When to use

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

===Dispersed control style===

Line 123 ⟶ 118:

===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<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"|date=2004|volume=30|issue=8|url=http://ieeexplore.ieee.org/document/1316869/citations}}</ref>.

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