Fall Semester, 2001
Some Design Heuristics
© 2001, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 29-Nov-01
|
|
CS 535 Object-Oriented Programming & Design Fall Semester, 2001 Some Design Heuristics |
|
|---|---|---|
|
© 2001, All Rights Reserved, SDSU & Roger Whitney San Diego State University -- This page last updated 29-Nov-01 |
Meyer's Goals for Modular software
Decomposability
Decompose problem into smaller subproblems
that can be solved separately
Example: Top-Down Design
Counter-example: Initialization Module
Meyer's Goals for Modular software Composability
Freely combine modules to produce new systems
Examples: Math libraries
Unix command & pipes
Meyer's Goals for Modular software Understandability
Individual modules understandable by human reader
Counter-example: Sequential Dependencies
Meyer's Goals for Modular software Continuity
Small change in specification results in:
Changes in only a few modules
Does not affect the architecture
Example: Symbolic Constants
const MaxSize = 100
Meyer's Goals for Modular software Protection
Effects of an abnormal run-time condition is confined to a few modules
Example: Validating input at source
Design Heuristics
Some Basic Design Heuristics
2.1 All data should be hidden within its class
2.9 Keep related data and behavior in one place
3.3 Beware of classes that have many accessor methods defined in their public interfaces. Having many implies that related data and behavior are not being kept in one place
All data should be hidden within its class
Each time you wish to make an instance variable public ask:
What am I trying to do with this data and why is it not being done in the class for me?
Is the data in the correct class?
Public instance variables verses accessor methods
Public instance variables
Smalltalk.CS535 defineClass: #Customer instanceVariableNames: 'name phone id ' id ^id
id
^id isNil
ifTrue: [id := 0 asValue]
ifFalse: [id]
id ^id value
Keep related data and behavior in one place
Data and behavior are part of the same abstraction
If they are not in the same place we have to violate previous heuristic
Keeping multiple copies of the data in different places is not keeping it in one place
Beware of many public accessor methods in a class
Having many implies that related data and behavior are not being kept in one place
Example Heating Problem
Example from Booch and used in Riel's text
Room has
Solution 1
Solution 2
Extremes - God class and Proliferation of Classes
God class
God Class Heuristics
2.8 A class should capture one and only one key abstraction
3.1 Distribute system intelligence horizontally as uniformly as possible
3.2 Do not create god classes/objects in your systems
2.10 Spin off nonrelated information into another class
3.4 Beware of classes that have too much noncommunicating behavior
4.6 Most of the methods defined in a class should be using most of the data members most of the time
A class should capture one and only one key abstraction
A god class does many things
Sometimes it is hard to determine what it is
If you have too many classes, some of them may not represent an abstraction
One sentence description of the class
Distribute system intelligence horizontally as uniformly as possible
Top-level classes in a design should share the work
God classes tend to do most of the work
Do not create god classes/objects in your systems
Beware of classes whose names contains:
2.10 Spin off nonrelated information into another class
3.4 Beware of classes that have too much noncommunicating behavior
4.6 Most of the methods defined in a class should be using most of the data members most of the time
Proliferation of Classes Heuristics
2.11 Be sure that abstractions that you model are classes and not simply the roles objects play
5.15 Do not turn objects of a class into subclasses of the class
3.7 Eliminate irrelevant classes from your design.
3.8 Eliminate classes that are outside the system.
3.9 Do not turn an operation into a class
Model classes and roles objects play
Do not turn objects of a class into subclasses of the class
Is RentalItem a class or a role for an Item object?
Is OverDueRentalItem a class or a role for a RentalItem object
Eliminate irrelevant classes from your design
Irrelevant class
Eliminate classes that are outside the system
Actors are an example of things outside the system
Actor is a role that users play with respect to the system
Do not turn an operation into a class
Beware of a class whose name is a verb or derived from a verb
Check to see if such classes have more than one meaningful behavior
May need to move the behavior to a different class
Example
IOHandler Class
Methods:
Common Minimal Public Interface
2.4 Implement a minimal public interface that all classes understand
This can be applied a global Object class, but also applies to classes in a project or domain
Java’s Object clone()
|
notify() |
wait(long
timeout)
|
|
notifyAll() |
wait(long
timeout, int nanos)
|
|
wait() |
|
Operations, Classes, Methods
Relationships between Objects
Type of Relations:
|
Type |
Relation
between
|
|
Uses |
(Object) |
|
Containment |
(Object) |
|
Inheritance |
(Class) |
|
Association |
(Object) |
Six different Ways to Implement Uses
How does the sender access the receiver ?
1. Containment
class Sender {
Receiver here;
public void method() {
here.sendAMessage();
}
}
class Sender {
public void method(Receiver here) {
here.sendAMessage();
}
}
3.
Ask
someone else
class Sender {
public void method() {
Receiver here = someoneElse.getReceiver();
here.sendAMessage();
}
}
class Sender {
public void method() {
Receiver here = new Receiver();
here.sendAMessage();
}
}
Heuristics for the Uses Relationship
4.1 Minimize the number of classes with another class collaborates
4.2 Minimize the number of message sends between a class and its collaborator
4.3 Minimize the number of different messages a class sends to another class.
4.4 Minimize the product of the number of methods in a class and the number of different messages they send.
Which is more complex?
Containment Relationship
4.5 If class A contains objects of class B, then A should be sending messages to its fields of type B.
This heuristic prohibits:
class Foo {
Bar data;
public Bar getData() {
return data;
}
public void setData( Bar newData) {
data = newData;
}
}
Narrow and Deep Containment Hierarchies
Combining fields into new classes can reduce the number of fields in a class
A broad and shallow Containment Hierarchy
A narrow and deep Containment Hierarchy
4.8 Distribute system intelligence vertically down narrow and deep containment hierarchies.
No Talking between Fields
4.14 Objects that are contained in the same containing class should not have a uses relationship between them.
Contained Objects with uses relationships
The containing class should send messages to the contained objects
4.13 A class must know what it contains, but it should not know who contains it.
If a number of classes depend on each other in a complex way, you can violate 4.13 to reduce the number of classes they interact with.
Wrap the classes in a containing class.
Each contained class sends a message to the containing class, which broadcasts the message to the proper contained objects
Complex interactions
Replacing complex interaction with containing class
Copyright ©, All rights reserved.
2000 SDSU & Roger Whitney, 5500 Campanile Drive, San Diego, CA 92182-7700 USA.
OpenContent license defines the copyright on this document.
Previous visitors since 29-Nov-01 Next