See more Responsibility driven design articles on AOD.

Powered by
TTSReader
Share this page on
Article provided by Wikipedia


( => ( => ( => Responsibility-driven design [pageid] => 26472355 ) =>

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 is responsible for and the information that the object shares. It was proposed by "Rebecca Wirfs-Brock and Brian Wilkerson

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

In the "client–server model they refer to, both the client and the server are "classes or "instances of classes. At any particular time, either the client or the server represents an object. Both the parties commit to a "contract and exchange information by adhering to it. The client can only make the requests specified in the contract and the server must answer these requests.[1] 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, 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 functions should be finely grained, such as in "Eiffel programming language. Even finer control of the visibility of even classes is available in the "Newspeak programming language.

Contents

Overview[edit]

Responsibility-driven design focuses on the objects as behavioral abstractions which are characterized by their responsibilities. The "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.[2] This makes the design follow type hierarchy for inheritance which improves encapsulation and makes it easier to identify abstract classes. It can also group the classes together based on their clients which is considered a unique ability.

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 distributed systems. Similarly, it can help to design and maintain explanation facilities for cognitive models, intelligent agents, and other knowledge-based systems.[3]

Building blocks[edit]

In their book Object Design: Roles, Responsibilities and Collaborations,[4] the authors describe the following building blocks that make up responsibility-driven design.

Objects[edit]

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.[5]

Roles[edit]

Object role refers to an exterior view of what general service is offered by the object. It is a set of related responsibilities.[5] It can be implemented as a class or an interface. Interface, however, is the preferred implementation as it increases flexibility by hiding the concrete class which ultimately does the work.[12]

Role Stereotypes: Role stereotypes are simplified roles that come with predefined responsibilities.[13] There are several categories.

Control style[edit]

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

Centralized control style[edit]

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
Disadvantages
When to use

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

Delegated control style[edit]

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]
Advantages
Disadvantages
When to use

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

Clustered control style[edit]

This control style is a variation of the centralized control style wherein control is factored among a group of objects whose actions are coordinated.[19] 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.[20]

Dispersed control style[edit]

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.[21]

Advantages
Disadvantages
When to use

Never.

Preferred control style[edit]

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.[17]

Conflict with the Law of Demeter[edit]

According to Wirfs-Brock and Wilkerson, there is a conflict between the "Law of Demeter and responsibility-driven design. The law says that messages can be sent only to the following: message argument, instance variable, new objects, and 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." [1]

References[edit]

  1. ^ a b Wirfs-Brock, Rebecca; Wilkerson, Brian (1989). "Object-Oriented Design: A Responsibility-Driven Approach". ACM SIGPLAN Notices. 24 (10): 74. "doi:10.1145/74878.74885. Retrieved 9 February 2016. 
  2. ^ Anthony J. H. Simons; Monique Snoeck; Kitty Hung (1998). "Design Patterns as Litmus Paper to Test the Strength of Object-Oriented Methods". "doi:10.1007/978-1-4471-0895-5_10. 
  3. ^ Steven R. Haynes; Isaac G. Councill; Frank E. Ritter (2004). "Responsibility-Driven Explanation Engineering for Cognitive Models". 
  4. ^ Wirfs-Brock, Rebecca; McKean, Alan (2003). Object Design: Roles, Responsibilities, and Collaborations. Indianapolis, IN: Addison-Wesley. "ISBN "0201379430. 
  5. ^ a b c d e Wirfs-Brock & McKean 2002, pp. 3
  6. ^ Wirfs-Brock & McKean 2002, pp. 58
  7. ^ a b c Wirfs-Brock & McKean 2002, pp. 61
  8. ^ a b Wirfs-Brock & McKean 2002, pp. 72
  9. ^ a b Wirfs-Brock & McKean 2002, pp. 17
  10. ^ a b Wirfs-Brock & McKean 2002, pp. 126
  11. ^ a b c Wirfs-Brock & McKean 2002, pp. 168
  12. ^ Wirfs-Brock & McKean 2002, pp. 340
  13. ^ a b c d e Wirfs-Brock & McKean 2002, pp. 4
  14. ^ a b c d e f Wirfs-Brock & McKean 2002, pp. 93
  15. ^ a b c Wirfs-Brock & McKean 2002, pp. 165
  16. ^ Wirfs-Brock & McKean 2002, pp. 164
  17. ^ a b Eric, Arisholm; Dag I.K., Sjoberg (2004). ""Evaluating the effect of a delegated versus centralized control style on the maintainability of object-oriented software"". 30 (8). 
  18. ^ Wirfs-Brock & McKean 2002, pp. 196
  19. ^ Wirfs-Brock & McKean 2002, pp. 197
  20. ^ Wirfs-Brock & McKean 2002, pp. 213
  21. ^ Wirfs-Brock & McKean 2002, pp. 30

Bibliography[edit]

) )