Responsibility-driven design: Difference between revisions

Revision as of 19:35, 18 February 2019

Latest revision as of 12:57, 10 January 2025

(7 intermediate revisions by 5 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.

Line 4 ⟶ 6:

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

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|pages = 521–534|doi = 10.1109/TSE.2004.43|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.