Professional Documents
Culture Documents
Object-Oriented Design
Reading:
Object Oriented Design Heuristics Ch. 2-3,
by Authur Riel
These lecture slides are copyright (C) Marty Stepp, 2007. They may not be rehosted, sold, or
modified without expressed permission from the author. All rights reserved.
1
Big questions
What is a "god class" ?
What forms can a god class take?
How do we spot a god class in our system, and how do we get
rid of it?
2
Chapter 2:
Classes and Objects
3
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.
4
OO design pyramid
5
Qualities of modular software
decomposable
can be broken down into pieces
composable
pieces are useful and can be combined
understandable
one piece can be examined in isolation
has continuity
reqs. change affects few modules
protected / safe
an error affects few other modules 6
Interface and implementation
public interface: data and behavior of the object that
can be seen and executed externally by "client" code
private implementation: internal data and methods
in the object, used to help implement the public
interface, but cannot be directly accessed
client: code that uses your class/subsystem
Example: radio
public interface is the speaker, volume buttons, station dial
private implementation is the guts of the radio; the transistors,
capacitors, voltage readings, frequencies, etc. that user should not
see
7
Some methods should be private!
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.8: A class should capture one and only one key
abstraction.
(bad) example: PokerGame class that holds all the players, holds an
array representing the card deck, stores all bets and money, does
the logic for each betting round...
10
Reducing coupling
Some ways to reduce coupling:
combine two classes that don't represent a whole
abstraction
example: Bet and Round
12
Roles of objects
Heuristic 2.11: Be sure the abstractions that you
model are classes and not simply the roles objects play.
13
Interfaces and inheritance
interfaces should be used when you want:
polymorphism: treat different types of objects the same way
examples: Java's collection framework
List --> LinkedList, ArrayList; Map --> HashMap,
TreeMap
Iterator; Comparable
16
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.
17
"God class" problem
god class: a class that hoards too much of the data or
functionality of a system. (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.
18
Forms of god classes
behavioral god class: holds too much logic
often has a name ending with "System", "Manager"
19
Eliminating god classes
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
lots of accessors are okay on a class with important data that
needs to be shown by a GUI
20
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
21
Model-view-controller
model-view-controller (MVC): common design
paradigm for graphical systems
controller classes 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)
data for
rendering
Model View
View
Component
Model updates events
Controller
Controller
22
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
23
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!
25
Misused controllers, cont'd.
potential problems with controller classes
data and behavior should be together, not in separate classes
controller classes are basically the action-oriented paradigm
difficult to ask a piece of data, "what depends on you?"
27
Proliferation of classes
proliferation of classes: A system that has too many
classes that are too small in size and scope, making the
system hard to use, debug, and maintain
Heuristic 3.7: Eliminate irrelevant classes from your design.
irrelevant classes often have only get/set methods
28
Agent classes
What is an "agent class?" Is it good or bad to have
them in your system?
Model
business logic
Get Set
Update
State State
Event Change
View
View Controller