Upload
marjorie-goodman
View
214
Download
0
Tags:
Embed Size (px)
Citation preview
1
TCSS 360, Spring 2005Lecture Notes
Design Guidelines 2
Relevant Reading:Object-Oriented Design Heuristics
Arthur Riel
2
Action vs. object-oriented
What is the difference between an "action-oriented" and "object-oriented" application?
action-oriented: procedural: functional decomposition easy to find data dependencies by looking at
function headers not easy to find functional dependencies by
looking at pieces of data (see fig 3.3, p31) object-oriented:
data decomposition, decentralized functionality data in front of coder's mind, functionality in
back
3
When action-oriented works
When does it work better to use an action-oriented style for application building? when they put the data in the same file with
the functions on it; essentially makes a class so why not just make it a class? forces
programmer to use good conventions forces coders to stick with good design
4
"God class" problem
What are "god classes?" What is wrong with having a "god class" in your system? god class: a class that hoards too much of the data
or functionality of a system. (problem: not modular!)
Heuristic 3.1: Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly.
Heuristic 3.2: Do not create god classes/objects in your system. Be very suspicious of a class whose name contains Driver, Manager, System, or Subsystem.
Heuristic 3.4: Beware of classes that have too much non-communicating behavior, that is, methods that operate on a proper subset of the data members of a class. God classes often exhibit much non-communicating behavior.
5
Forms of god classes behavioral god class: holds too much of
system's logic often has a name ending with "System", "Manager"
data god class: holds too much of system's data often has a bunch of access / search methods
6
Related data and behavior Heuristic 3.3: Beware of classes that have
many accessor methods defined in their public interface. Having many implies that related data and behavior are not being kept in one place. location of "policy" behavior should be in the place
where that policy is enforced / enacted What's wrong with the 2 following designs? each has policy behavior in a class that shouldn't
have it
7
"Controller" classes
What is a "controller" class? Is it good or bad? controller class: a class that only contains behavior
(might contain some fields, but they are superfluous) usually grabs state from other classes and acts on it often has an "-er" or "-or" verb phrase as its name, such as
DataLoader, PasswordChecker
similar to a behavioral God class on a smaller scale design on right below has a controller class
(checking of prereqs should be done by course offering)
8
Controllers, cont'd. problems with controller classes
data (entity) and behavior (control) should be together, not in separate classes
controller classes are basically the action-oriented paradigm
it becomes difficult to ask a piece of data, "what functionality depends on you?"
in the real world, people dislike controllers... microwave, radio, car have data and behavior together VCR / tape has control separate because controller is
expensiveWhat about a TV? It has remote control separate; why? physical convenience, price, dependency; you never
want one without the other
9
Model and view model: classes in your system that are related
to the internal representation of the state of the system
often part of the model is connected to file(s) or database(s) examples (card game): Card, Deck, Player examples (bank system): Account, User, UserList
view: classes in your system that display the state of the model to the user
generally, this is your GUI (could also be a text UI) should not contain crucial application data Different views can represent the same data in different ways
Example: Bar chart vs. pie chart examples: PokerPanel, BankApplet
10
Model-view-controller model-view-controller (MVC): common
design paradigm for graphical systems controller: classes that connect model and
view defines how user interface reacts to user input
(events) receives messages from view (where events come
from) sends messages to model (tells what data to display) sometimes part of view (see left)
Model
Controller
View
data for renderin
g
eventsupdatesModel
ViewComponent
Controller
11
Advantages of MVC decreases coupling
simplifies complex user interface code multiple controllers may be defined based on desired
behavior changes to part can affect others without requiring
the changed object to know details of others increases cohesion
only the view is concerned with pixels and screen-based data
improved flexibility new views can be added without changing model change the feel (controller) without changing the
look (view) increases reuse
one model can be represented in several ways
12
Model-view separation Heuristic 3.5: In applications that consist of an
object-oriented model interacting with a user interface, the model should never be dependent on the interface. The interface should be dependent on the model. (bad) example: Making a system with lots of classes
that know how to render themselves; the GUI just calls card.draw(), deck.draw(), player.draw().
GUI should render them, not delegate! doesn't this violate Heuristic 2.9: Keep related data and
behavior in one place? Shouldn't things know how to draw themselves? the behavior of drawing things is related to the GUI, because it is part of the GUI's appearance. So it belongs in the GUI classes. Having things draw themselves locks them in to one representation.
13
Representing the real world
Heuristic 3.6: Model the real world whenever possible. Example of room heat: fig 3.7 - 3.9, p37-38 model the room as a way to decide if heat is needed, and to
encapsulate sensors
14
Proliferation of classes
What is the "proliferation of classes" problem? proliferation of classes: When object-oriented
design leads us to design a system that has too many classes that are too small in size and scope, making the system hard to use, debug, and maintain ("ravioli code")
Heuristic 3.7: Eliminate irrelevant classes from your design.
irrelevant classes often have only get/set methods Heuristic 3.8: Eliminate classes that are outside the
system. don't model behavior of a blender just because you sell
blenders; don't model a user just because they show up with a ticket
Heuristic 3.9: Do not turn an operation into a class. Be suspicious of any class whose name is a verb, especially
those that have only one piece of meaningful behavior. Ask if that piece of behavior needs to be migrated to some existing or undiscovered class.
15
Agent classes What is an "agent class?" How does it differ from a
controller? Is it good or bad to have them in your system? agent class: a class that acts as a middle-man to
help two or more other classes communicate with each other.
different from controller because it doesn't contain heavy logic
example: Farmer class to link Cow and Milk classes example: Librarian class to link Book and Shelf classes
Heuristic 3.10: Agent classes are often placed in the analysis model of an application. During design time, many agents are found to be irrelevant and should be removed.
what defines whether an agent is relevant? a relevant agent must have some other behavior beyond
simply being a middle-man; it must have some useful purpose of its own
16
Is the controller relevant? in the model-view-controller paradigm,
the controller acts largely as an agent Should it be there?
ViewView
model representation
ModelModel
business logic
ControllerController
user interaction
UpdatUpdatee
EventEvent
UserUserActionAction
ss
ChangChangee
ViewView
SetSet
StateState
GetGetStateState
17
In-class exercise In your project groups, define a set of classes and their
major attributes and operations, for a calendar management system.
Multiple users should be able to use the system to create appointments (either individual appointments or group meetings), see an overview of their calendars at various levels of granularity (day, week, month), edit or delete existing appointments, and set reminders to go off for an existing appointment. Appt. data should be persistent (save and load).
What classes would you use in this system? What model would you use? What data would it contain? What views of the model(s) would you want?
After some time to discuss, we'll do a quick discussion of each group's design and critique it.
18
Heuristics 2 quick reference
Heuristic 2.1: All data should be hidden within its class. Heuristic 2.2: Users of a class must be dependent on its public interface,
but a class should not be dependent on its users. Heuristic 2.3: Minimize the number of messages in the protocol of a class. Heuristic 2.4: Implement a minimal public interface that all classes
understand. Heuristic 2.5: Do not put implementation details such as common-code
private functions into the public interface of a class. Heuristic 2.6: Do not clutter the public interface of a class with items that
users of that class are not able to use or are not interested in using. Heuristic 2.7: Classes should only exhibit nil or export coupling with other
classes, that is, a class should only use operations in the public interface of another class or have nothing to do with that class.
Heuristic 2.8: A class should capture one and only one key abstraction. Heuristic 2.9: Keep related data and behavior in one place. Heuristic 2.10: Spin off nonrelated behavior into another class (i.e.,
noncommunicating behavior). Heuristic 2.11: Be sure the abstractions that you model are classes and
not simply the roles objects play.
19
Heuristics 3 quick reference
Heuristic 3.1: Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly.
Heuristic 3.2: Do not create god classes/objects in your system. Be very suspicious of a class whose name contains Driver, Manager, System, or Subsystem.
Heuristic 3.3: Beware of classes that have many accessor methods defined in their public interface.
Heuristic 3.4: Beware of classes that have too much noncommunicating behavior. Heuristic 3.5: In applications that consist of an object-oriented model interacting
with a user interface, the model should never be dependent on the interface. Heuristic 3.6: Model the real world whenever possible. Heuristic 3.7: Eliminate irrelevant classes from your design. Heuristic 3.8: Eliminate classes that are outside the system. Heuristic 3.9: Do not turn an operation into a class. Be suspicious of any class
whose name is a verb or is derived from a verb, especially those that have only one piece of meaningful behavior (don't count set, get, print).
Heuristic 3.10: Agent classes are often placed in the analysis model of an application. During design time, many agents are found to be irrelevant and should be removed.