Knowledge

Responsibility-driven design

Source đź“ť

36: 226:
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
185:
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. Thus, responsibility-driven design tries to avoid dealing with details, such as the way in which requests are carried out, by instead only specifying
477:
A delegated control style lies in between a centralized and dispersed control style. It passes some of the decision making and much of the action to objects surrounding a control center. Each neighboring object has a significant role to play. It can also be called as event driven model, where the
546:
This control style is a variation of the centralized control style wherein control is factored among a group of objects whose actions are coordinated. The main difference between a clustered and delegated control style is that in a clustered control style, the decision making objects are located
342:
Object role refers to an exterior view of what general service is offered by the object. It is a set of related responsibilities. It can be implemented as a class or an interface. Interface, however, is the preferred implementation as it increases flexibility by hiding the concrete class which
218:
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. This makes the design follow type hierarchy for inheritance which improves encapsulation and makes it easier to identify
595:
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.
193:
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
359:
Information Provider: A slight variation of an information holder is the information provider, which takes a more active role in managing and maintaining information. This distinction can be used if a designer needs to get more
391:
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
555:
A dispersed control style does not contain any control centers. The logic is spread across the entire population of objects, keeping each object small and building in as few dependencies among them as possible.
406:
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.
306:
Objects are described as things that have machine-like behaviors that can be plugged together to work in concert. These objects play well-defined roles and encapsulate scripted responses and information.
274:
Content of unlined side: On this side the candidate's name, its purpose in the application, stereotype roles and anything worthwhile such as the names of roles in patterns it participates in are recorded.
403:
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.
1022:. 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. 427:
Manager model : The control of the objects in the application is in with only one object. Generally, it is implemented in concurrent models. It can also be implemented in sequential model using
268:
CRC Cards: CRC stands for Candidates, Responsibilities, Collaborators. They are index cards used in early design for recording candidates. These cards are split up into an unlined and a lined side.
158:
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
368:
External Interfacer: External interfacer communicates with other applications rather than its own. It is mainly used for encapsulating non-object-oriented APIs and does not collaborate a lot.
282:
Hot Spot Cards: Hot Spot Cards are used for recording variations with just enough detail so you can discriminate important difference. Similar to CRC cards, these are also created from
323:
Subresponsibilities: Sometimes, a large or complicated responsibility is split up into smaller ones called subresponsibilities. They are further categorized based on what they do.
415:
This control style inflicts a procedural paradigm on the structure of the application and places major-decision making responsibilities in only a few objects or a single object.
262:
Candidates: Candidates or candidate objects are key concepts in the form of objects described on CRC cards. They serve as initial inventions in the process of object design.
424:
Call-return model : The control of the objects in the application is in hierarchical way. Control starts at root and moves downwards. It is used in a sequential model.
933:
Eric, Arisholm; Dag I.K., Sjoberg (2004). "Evaluating the effect of a delegated versus centralized control style on the maintainability of object-oriented software".
314:
Responsibilities: A responsibility is an obligation to perform a task or know information. These are further categorized according to their usage scenario.
928: 926: 317:
Public Responsibilities: Public responsibilities are the responsibilities an object offers as services to others and the information it provides to others.
374:
User Interfacer: User interfacer communicates with users by responding to events generated in the UI and then passing them on to more appropriate objects.
923: 57: 50: 365:
Interfacer: This role transforms information and requests between distinct parts of an application. It is further divided into more specific roles.
507:
Though there is an external coordinator, Objects can be made smarter to know what they are supposed to do and can be reused in other applications.
487:
Broadcast model : An event is broadcast to all objects in the application. The object which can handle the event can acquire the control.
100: 17: 72: 79: 346:
Role Stereotypes: Role stereotypes are simplified roles that come with predefined responsibilities. There are several categories.
215: 86: 1039: 677: 1058: 187: 320:
Private Responsibilities: Private responsibilities are the actions an object takes in support of public responsibilities.
68: 717: 575:
When you want to find out how something works, you must trace the sequence of requests for services across many objects
181:
of classes. At any particular time, either the client or the server represents an object. Both the parties commit to a
119: 279:
Hot Spots: Hot Spots are points in the application where variations occur. They are recorded using Hot Spot Cards.
271:
Content of lined side: On this side the candidate's name, its responsibilities and its collaborators are recorded.
199: 195: 329:
Sequencing Responsibilities: These refer to the sequencing of the execution of subordinate responsibilities.
174: 350:
Controller: Object implementing this role makes decisions and closely directs the action of other objects.
93: 371:
Internal Interfacer: Also called intersystem interfacer. It act as a bridge between object neighborhoods.
178: 136: 382:
Structurer: This role maintains relationships between objects and information about those relationships.
190:, since the specification of the exact way in which a request is carried out is private to the server. 223:. It can also group the classes together based on their clients which is considered a unique ability. 148: 660: 1063: 240: 170: 159: 140: 46: 255:, the authors describe the following building blocks that make up responsibility-driven design. 655: 198:
programming language. Even finer control of the visibility of even classes is available in the
311:
Object Neighborhoods: Another term for subsystem. It is a logical grouping of collaborators.
265:
Collaborations: A collaboration is defined as an interaction of objects or roles (or both).
8: 152: 529:
Too much distribution of responsibility can lead to weak objects and weak collaborations
950: 547:
within a control center whereas in a delegated control style they are mostly outside.
326:
Subordinate Responsibilities: These include the major steps in each subresponsibility.
1035: 713: 673: 510:
Delegating coordinators tend to know about fewer objects than dominating controllers.
236: 211: 400:
Concept of Control : The responsibilities and collaborations among the classes.
228: 954: 942: 665: 626: 428: 259:
Application: A software application is referred to as a set of interacting objects.
151:
is responsible for and the information that the object shares. It was proposed by
669: 648:"Design Patterns as Litmus Paper to Test the Strength of Object-Oriented Methods" 232: 692: 1031: 220: 1052: 457:
Objects can become coupled indirectly through the actions of their controller
645: 231:. Similarly, it can help to design and maintain explanation facilities for 163: 1019: 494:
handler to process the interrupt and passes to some object to process it.
469:
When decisions to be made are few, simple, and related to a single task.
946: 631: 614: 379:
Service Provider: This role performs work and offers computing services.
478:
control is delegated to the object requesting it to process the event.
356:
Information Holder: Information holder knows and provides information.
283: 538:
When one wants to delegate work to objects that are more specialized.
353:
Coordinator: This role reacts to events by delegating tasks to others.
491: 695:"Responsibility-Driven Explanation Engineering for Cognitive Models" 35: 182: 144: 694: 647: 454:
Controllers can become dependent on information holders' contents
516:
It is easy to change as changes typically affect fewer objects.
693:
Steven R. Haynes; Isaac G. Councill; Frank E. Ritter (2004).
578:
Not very reusable because no single object contributes much
1028:
Object Design: Roles, Responsibilities, and Collaborations
710:
Object Design: Roles, Responsibilities, and Collaborations
615:"Object-Oriented Design: A Responsibility-Driven Approach" 186:
the intent of a certain request. The benefit is increased
646:
Anthony J. H. Simons; Monique Snoeck; Kitty Hung (1998).
295:
At least two specific examples where the variation occurs
253:
Object Design: Roles, Responsibilities and Collaborations
1020:
Object-oriented design: a responsibility-driven approach
393: 214:
which are characterized by their responsibilities. The
901: 899: 897: 828: 826: 824: 811: 809: 210:
Responsibility-driven design focuses on the objects as
884: 882: 880: 878: 876: 874: 701: 519:
It is easier to divide design work among team members.
162:, which is concerned with using data to determine the 861: 859: 857: 855: 853: 796: 794: 781: 779: 766: 764: 762: 1026:
Wirfs-Brock, Rebecca; McKean, Alan (November 2002).
985: 973: 961: 911: 894: 838: 821: 806: 737: 735: 733: 731: 729: 612: 997: 871: 460:
The only interesting work is done in the controller
850: 791: 776: 759: 747: 173:they refer to, both the client and the server are 1025: 1003: 991: 979: 967: 917: 905: 888: 865: 844: 832: 815: 800: 785: 770: 753: 741: 726: 1050: 490:Interrupt-driven model : There will be the 227:the complexities of high-functionality large or 686: 613:Wirfs-Brock, Rebecca; Wilkerson, Brian (1989). 27:Design technique in object-oriented programming 606: 932: 639: 410: 139:, which improves encapsulation by using the 708:Wirfs-Brock, Rebecca; McKean, Alan (2003). 590: 550: 541: 472: 935:IEEE Transactions on Software Engineering 659: 630: 120:Learn how and when to remove this message 14: 1051: 56:Please improve this article by adding 712:. Indianapolis, IN: Addison-Wesley. 451:Control logic can get overly complex 292:General description of the variation 147:by considering the actions that the 29: 24: 441:Application logic is in one place. 246: 25: 1075: 386: 34: 1013: 69:"Responsibility-driven design" 13: 1: 1004:Wirfs-Brock & McKean 2002 992:Wirfs-Brock & McKean 2002 980:Wirfs-Brock & McKean 2002 968:Wirfs-Brock & McKean 2002 918:Wirfs-Brock & McKean 2002 906:Wirfs-Brock & McKean 2002 889:Wirfs-Brock & McKean 2002 866:Wirfs-Brock & McKean 2002 845:Wirfs-Brock & McKean 2002 833:Wirfs-Brock & McKean 2002 816:Wirfs-Brock & McKean 2002 801:Wirfs-Brock & McKean 2002 786:Wirfs-Brock & McKean 2002 771:Wirfs-Brock & McKean 2002 754:Wirfs-Brock & McKean 2002 742:Wirfs-Brock & McKean 2002 599: 58:secondary or tertiary sources 670:10.1007/978-1-4471-0895-5_10 133:Responsibility-driven design 18:Responsibility-Driven Design 7: 1059:Object-oriented programming 205: 137:object-oriented programming 10: 1080: 707: 343:ultimately does the work. 301: 286:. These cards consist of: 513:Dialogs are higher-level. 504:It is easy to understand. 411:Centralized control style 135:is a design technique in 337: 591:Preferred control style 551:Dispersed control style 542:Clustered control style 473:Delegated control style 241:knowledge-based systems 212:behavioral abstractions 160:data-driven programming 202:programming language. 45:relies excessively on 155:and Brian Wilkerson. 654:. pp. 129–147. 166:, not class design. 143:. It focuses on the 947:10.1109/TSE.2004.43 632:10.1145/74878.74885 619:ACM SIGPLAN Notices 229:distributed systems 171:client–server model 153:Rebecca Wirfs-Brock 141:client–server model 237:intelligent agents 1041:978-0-201-37943-3 679:978-1-85233-046-0 130: 129: 122: 104: 16:(Redirected from 1071: 1045: 1007: 1001: 995: 989: 983: 977: 971: 965: 959: 958: 930: 921: 915: 909: 903: 892: 886: 869: 863: 848: 842: 836: 830: 819: 813: 804: 798: 789: 783: 774: 768: 757: 751: 745: 739: 724: 723: 705: 699: 698: 690: 684: 683: 663: 643: 637: 636: 634: 610: 233:cognitive models 221:abstract classes 125: 118: 114: 111: 105: 103: 62: 38: 30: 21: 1079: 1078: 1074: 1073: 1072: 1070: 1069: 1068: 1064:Software design 1049: 1048: 1042: 1016: 1011: 1010: 1002: 998: 990: 986: 978: 974: 966: 962: 931: 924: 916: 912: 904: 895: 887: 872: 864: 851: 843: 839: 831: 822: 814: 807: 799: 792: 784: 777: 769: 760: 752: 748: 740: 727: 720: 706: 702: 691: 687: 680: 661:10.1.1.130.8713 644: 640: 611: 607: 602: 593: 553: 544: 475: 413: 389: 340: 304: 249: 247:Building blocks 208: 126: 115: 109: 106: 63: 61: 55: 51:primary sources 39: 28: 23: 22: 15: 12: 11: 5: 1077: 1067: 1066: 1061: 1047: 1046: 1040: 1032:Addison Wesley 1023: 1015: 1012: 1009: 1008: 996: 994:, pp. 213 984: 982:, pp. 197 972: 970:, pp. 196 960: 941:(8): 521–534. 922: 920:, pp. 164 910: 908:, pp. 165 893: 870: 849: 847:, pp. 340 837: 835:, pp. 168 820: 818:, pp. 126 805: 790: 775: 758: 746: 725: 719:978-0201379433 718: 700: 685: 678: 638: 604: 603: 601: 598: 592: 589: 585: 584: 580: 579: 576: 572: 571: 567: 566: 562: 561: 552: 549: 543: 540: 536: 535: 531: 530: 526: 525: 521: 520: 517: 514: 511: 508: 505: 501: 500: 496: 495: 488: 484: 483: 474: 471: 467: 466: 462: 461: 458: 455: 452: 448: 447: 443: 442: 438: 437: 433: 432: 429:case statement 425: 421: 420: 412: 409: 408: 407: 404: 401: 388: 385: 384: 383: 380: 377: 376: 375: 372: 369: 363: 362: 361: 354: 351: 339: 336: 335: 334: 333: 332: 331: 330: 327: 321: 318: 312: 303: 300: 299: 298: 297: 296: 293: 290: 280: 277: 276: 275: 272: 266: 263: 260: 251:In their book 248: 245: 207: 204: 128: 127: 42: 40: 33: 26: 9: 6: 4: 3: 2: 1076: 1065: 1062: 1060: 1057: 1056: 1054: 1043: 1037: 1033: 1029: 1024: 1021: 1018: 1017: 1006:, pp. 30 1005: 1000: 993: 988: 981: 976: 969: 964: 956: 952: 948: 944: 940: 936: 929: 927: 919: 914: 907: 902: 900: 898: 891:, pp. 93 890: 885: 883: 881: 879: 877: 875: 867: 862: 860: 858: 856: 854: 846: 841: 834: 829: 827: 825: 817: 812: 810: 803:, pp. 17 802: 797: 795: 788:, pp. 72 787: 782: 780: 773:, pp. 61 772: 767: 765: 763: 756:, pp. 58 755: 750: 743: 738: 736: 734: 732: 730: 721: 715: 711: 704: 696: 689: 681: 675: 671: 667: 662: 657: 653: 649: 642: 633: 628: 624: 620: 616: 609: 605: 597: 588: 582: 581: 577: 574: 573: 570:Disadvantages 569: 568: 564: 563: 559: 558: 557: 548: 539: 533: 532: 528: 527: 524:Disadvantages 523: 522: 518: 515: 512: 509: 506: 503: 502: 498: 497: 493: 489: 486: 485: 481: 480: 479: 470: 464: 463: 459: 456: 453: 450: 449: 446:Disadvantages 445: 444: 440: 439: 435: 434: 430: 426: 423: 422: 418: 417: 416: 405: 402: 399: 398: 397: 395: 387:Control style 381: 378: 373: 370: 367: 366: 364: 358: 357: 355: 352: 349: 348: 347: 344: 328: 325: 324: 322: 319: 316: 315: 313: 310: 309: 308: 294: 291: 289:Hot Spot Name 288: 287: 285: 281: 278: 273: 270: 269: 267: 264: 261: 258: 257: 256: 254: 244: 242: 238: 234: 230: 224: 222: 217: 213: 203: 201: 197: 191: 189: 188:encapsulation 184: 180: 176: 172: 167: 165: 161: 156: 154: 150: 146: 142: 138: 134: 124: 121: 113: 110:December 2012 102: 99: 95: 92: 88: 85: 81: 78: 74: 71: â€“  70: 66: 65:Find sources: 59: 53: 52: 48: 43:This article 41: 37: 32: 31: 19: 1027: 1014:Bibliography 999: 987: 975: 963: 938: 934: 913: 868:, pp. 4 840: 749: 744:, pp. 3 709: 703: 688: 651: 641: 622: 618: 608: 594: 586: 554: 545: 537: 476: 468: 414: 390: 345: 341: 305: 252: 250: 239:, and other 225: 209: 192: 168: 164:control flow 157: 132: 131: 116: 107: 97: 90: 83: 76: 64: 44: 583:When to use 534:When to use 465:When to use 284:index cards 1053:Categories 625:(10): 74. 600:References 560:Advantages 499:Advantages 436:Advantages 394:subsystems 80:newspapers 47:references 656:CiteSeerX 492:interrupt 360:specific. 179:instances 216:CRC-card 206:Overview 200:Newspeak 183:contract 145:contract 955:6396127 652:Oois'98 587:Never. 302:Objects 175:classes 169:In the 94:scholar 1038:  953:  716:  676:  658:  196:Eiffel 149:object 96:  89:  82:  75:  67:  951:S2CID 482:Types 419:Types 338:Roles 101:JSTOR 87:books 1036:ISBN 714:ISBN 674:ISBN 565:None 73:news 943:doi 666:doi 627:doi 177:or 49:to 1055:: 1034:. 1030:. 949:. 939:30 937:. 925:^ 896:^ 873:^ 852:^ 823:^ 808:^ 793:^ 778:^ 761:^ 728:^ 672:. 664:. 650:. 623:24 621:. 617:. 396:. 243:. 235:, 60:. 1044:. 957:. 945:: 722:. 697:. 682:. 668:: 635:. 629:: 431:. 123:) 117:( 112:) 108:( 98:· 91:· 84:· 77:· 54:. 20:)

Index

Responsibility-Driven Design

references
primary sources
secondary or tertiary sources
"Responsibility-driven design"
news
newspapers
books
scholar
JSTOR
Learn how and when to remove this message
object-oriented programming
client–server model
contract
object
Rebecca Wirfs-Brock
data-driven programming
control flow
client–server model
classes
instances
contract
encapsulation
Eiffel
Newspeak
behavioral abstractions
CRC-card
abstract classes
distributed systems

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

↑