Content deleted Content added
Magioladitis (talk | contribs) m fixing stuff using AWB |
m Added reference links to some words like distributed systems and control flow |
||
Line 7:
</blockquote>
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=9 February 2016}}</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.
Line 16:
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 web | title=Design Patterns as Litmus Paper to Test the Strength of Object-Oriented Methods | year=1998 | url=http://citeweb.info/19980495062 | doi=10.1007/978-1-4471-0895-5_10 | author1=Anthony J. H. Simons | author2=Monique Snoeck | author3=Kitty Hung}}</ref> 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 [http://www.computerhope.com/jargon/d/distribs.htm distributed systems]. Similarly, it can help to design and maintain explanation facilities for cognitive models, intelligent agents, 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==
| |||