Responsibility-driven design: Difference between revisions

Revision as of 22:24, 24 January 2022

Latest revision as of 12:57, 10 January 2025

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