Unformatted text preview:

Lecture 20: Responsibility-Driven Design,Part 3Kenneth M. AndersonObject-Oriented Analysis and DesignCSCI 6448 - Spring Semester, 2003March 20, 2003 © University of Colorado, 2003 2Credit where Credit is Due Some material presented in this lectureis taken from Object Design: Roles,Responsibilities, and Collaborations. ©Addison Wesley/Pearson Education,2003. ISBN 0-201-37943-0March 20, 2003 © University of Colorado, 2003 3Responsibility-Driven Design Last Lecture Designing Collaborations This Lecture Designing Control Styles Or, how is the decision making processesof your application organized?March 20, 2003 © University of Colorado, 2003 4Application Control and Control Style How does an application respond to events?How does it make decisions? Typically via “control centers”; groups of objectsthat are in charge of the decision making process Control style affects how intelligence isdistributed among objects within a controlcenter A control style can be centralized, delegated,dispersed, or somewhere in betweenMarch 20, 2003 © University of Colorado, 2003 5Centralized Control A centralized control style places major decisionmaking responsibilities in a small number of objects;those stereotyped as controllers Most objects used by controllers are devoid of any significantdecision making responsibilities they are told what to do and they do it! A variation of this style is the clustered control style;here decision-making responsibilities are assigned toseveral controllers, each working on a small part ofthe overall control Typically there is then one controller which “controls” eachcluster; “one controller to rule them all and in the darknessbind them!” (obligatory Lord of the Rings reference!)March 20, 2003 © University of Colorado, 2003 6Problems With centralized control, generally one object (thecontroller) makes most of the important decisions This is good since it centralizes control logic, but… several problems can occur including Control logic can get overly complex All other classes may become information holders this means that most responsibilities move to the controllerwhich then loses cohesion Controllers can become dependent on the contents of theirinformation holders If the information changes, the controller has to change; if thereare too many information holders, the controller becomes highlycoupledMarch 20, 2003 © University of Colorado, 2003 7Delegated Control In a delegated control style, thedesigner makes a concerted effort todelegate decisions, not only betweencontrollers, but also to objects that haveother responsibilities Decisions made by controllers are limitedto deciding what should be done; otherobjects then perform that taskMarch 20, 2003 © University of Colorado, 2003 8Advantages Delegated control is more “object oriented” and leadsto several benefits Delegating coordinators tend to know about fewer objectsthan dominating controllers This leads to a loosely coupled system Changes typically affect fewer objects Dialogs are higher-level Collaborations between coordinators and the objects theycoordinate tend to be higher level requests rather than simplerequests to store and retrieve data e.g. calculateTaxes() versus getTaxRate() It is easier to divide design work among team members More objects with interesting responsibilities makes it easy todivide design and implementation work among thedevelopment teamMarch 20, 2003 © University of Colorado, 2003 9Problems Too much distribution of responsibility can lead toweak objects and weak collaborations Carried to extremes, a delegated control style can result inobjects that do not “know” or “do” enough to be interesting Look for these warning signs Small service provides used by a single client; the servicewas factored out of a controller and should be merged backin Complicated collaborations between delegator anddelegates; this can happen when not enough context ispassed with a request Lots of collaborations but not much work getting doneMarch 20, 2003 © University of Colorado, 2003 10Dispersed Control A dispersed control style distributesdecision-making responsibilities acrossmany objects involved in a task Benefits Decision making logic becomes very simple Problems May become hard to identify where a particulardecision is being made in a systemMarch 20, 2003 © University of Colorado, 2003 11Developing Control Centers In all but the simplest of applications, you willhave multiple control centers to design Control design is important when controlling user-initiated events complex processes work within a specific object neighborhood external software systems In each of these situations pick a control style, and work on specificresponsibilities and collaborationsMarch 20, 2003 © University of Colorado, 2003 12Mixing Styles However, do not try to use the same control styleeverywhere Develop a control style suited to each control situation; askthese questions How are decisions made in this situation? Who should make them? What decisions should be delegated? What patterns of delegation should be established andrepeated It is best to design collaborations so similar thingswork similarly For instance, use cases that handle the same kind of userinteractions should use the same control style even if theparticipating objects differMarch 20, 2003 © University of Colorado, 2003 13Example: Speak For Me Imagine a software system designed to help a severely disableduser, one who is paralyzed, blind, and cannot speak All this person can do is blink their eyes to indicate “yes” and “no” This system allows this user to compose and send messages byspeaking the alphabet and allowing the user to select letters toform into words and words into sentences The user can indicate words by selecting a “space”, which ispresented after the user has selected at least one letter Several two letter words are used as commands: ES for “endsentence”, SM for “send message”, etc. This system is similar to software used by Stephen Hawking, thefamous physicist, although he can see and can move his fingersMarch 20, 2003 © University of Colorado, 2003 14Example: Build a Message We are going to design a control center for SpeakFor Me that manages the process of building amessage Speak For


View Full Document

CU-Boulder CSCI 6448 - Responsibility-Driven Design

Documents in this Course
Struts

Struts

12 pages

Adapter

Adapter

23 pages

Prototype

Prototype

16 pages

Weka

Weka

15 pages

qooxdoo

qooxdoo

16 pages

Django

Django

12 pages

Overview

Overview

22 pages

XNA

XNA

5 pages

Load more
Download Responsibility-Driven Design
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Responsibility-Driven Design and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Responsibility-Driven Design 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?