Responsibility-driven design: Difference between revisions

Revision as of 21:03, 9 February 2017

Revision as of 21:09, 9 February 2017

Line 2:

'''Responsibility-driven design''' is a design technique in [[object-oriented programming]]. It was proposed by [[Rebecca Wirfs-Brock]] and Brian Wilkerson, who defined it as follows:

<blockquote>

Responsibility-driven design is inspired by the client/server[[client–server model]]. It focuses on the [[contract]] by asking:

* What actions is this object responsible for?

* What information does this object share?

</blockquote>

Responsibility-driven design is in direct contrast with data-driven design, which promotes defining the behavior of a class along 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.

TheIn the [[client/serverclient–server model]] model they refer to, assumesboth that a softwarethe client and a softwarethe server exchangeare information[[Class based(computer onprogramming)|classes]] aor contract[[Instance that(computer bothscience)|instances]] of classes. At any particular time, either the client or the server represents an object. Both the parties commit to adherea [[contract]] and exchange information by adhering to it. The client maycan only make the requests specified, in the contract and the server must answer themthese 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}}</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.

==Building blocks==