Responsibility-driven design: Difference between revisions

Revision as of 17:05, 29 October 2017

Latest revision as of 12:57, 10 January 2025

(10 intermediate revisions by 7 users not shown)

Line 1:

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

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

{{primary sources|date=December 2012}}

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

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 [[Class (computer programming)|classes]] or [[Instance (computer science)|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.<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|url=http://doi.acm.org/10.1145/74878.74885|accessdate-access=9 February 2016free}}</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 functions 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==

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 webbook | titlechapter=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 classesclass]]es. 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 [http://www.computerhope.com/jargon/d/distribs.htm distributed systems]. Similarly, it can help to design and maintain explanation facilities for [[cognitive modelsmodel]]s, [[intelligent agentsagent]]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>

==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=0201379430978-0201379433|ref=odrrc}}</ref> the authors describe the following building blocks that make up responsibility-driven design.

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

Line 57 ⟶ 59:

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"|journal = IEEE Transactions on Software Engineering|date=2004|volume=30|issue=8|urlpages =http:/ 521–534|doi = 10.1109/ieeexploreTSE.ieee2004.org/document/1316869/citations43|s2cid = 6396127}}</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.

Line 119 ⟶ 121:

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

==Conflict with the Law of Demeter==

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." <ref name="Wirfs-Brock1989"/>

==References==

Line 128 ⟶ 127:

==Bibliography==

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

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

[[Category:Object-oriented programming]]