| CS 535: Object-Oriented Programming & Design |
|
|---|
Fall Semester, 1997
Doc 27, Heuristics and Rules of Thumb
To Lecture Notes Index
San Diego State University -- This page last updated 08-Dec-97
Contents of Doc 27, Heuristics and Rules of Thumb
- References
- Multiple Inheritance
- Single Inheritance
- Metrics Rules of Thumb1
- Rules for Designing Reusability Classes2
- Rules for Finding Standard Protocols
- Rules for Finding Abstract Classes
- Rules for Finding Frameworks
Object-Oriented Design Heuristics, Riel, 1996
- Various sections in chapters 5-6 as indicated by the listed
heuristics
Designing Reusable Classes, Ralph Johnson and Brian Foote, Journal of
Object-Oriented Programming, 1(2):22-35, June/July 1988.
Object-Oriented Software Development: A Practical Guide, Mark Lorenz,
1993
6.1 If you have an example of multiple inheritance in your design, assume that
you have made a mistake and prove otherwise.
Multiple inheritance is not bad
Multiple inheritance is much rarer than many people think
Multiple inheritance is often overused
5.2 Parent classes should not know anything about their child (and grandchild,
etc.) classes.
5.3 All data in a parent class should be private to the child class
5.5 In practice inheritance hierarchies not be shallow, and not more than about
6 levels deep
- A well-developed class hierarchy should be several layers deep
Private and Protected Inheritance in C++
"Private and protected inheritance are simply warped forms of containment and
should be avoided"
Page 87 of Object-Oriented Design Heuristics
While the above statement may be extreme, it should point out to beginners to
avoid private and protected inheritance
Upper bound for average method size
- Language
- LOC Statements
- Smalltalk
- 8 5
- C++
- 24 15
-
-
Average number of methods per class should be less than 20
- Across multiple Smalltalk applications average number of methods per class
is in the range of 12-20
The average number of instance variables per class should be less than 6
The class hierarchy nesting level should be less than 6
- Start counting from framework classes
Metrics Rules of Thumb
The average number of comments lines per method should be greater than 1
The number of problem reports per class should be low
C++ will have 2 to 3 times the lines of code of Smalltalk
Code volume will expand in the first half of the project and decline in the
second half, as reviews clean up the system
Protocol
- Name and arguments of public operations of an object
Plug Compatible Objects
- Objects with the same protocol
-
-
Standard Protocol (Polymorphism)
- Similar processes have the same name
* Use small operations
- Smalltalk methods average about 3 - 8 lines of code
Rules for Finding Standard Protocols
* Reduce the number of arguments
- Methods with small number of arguments are more likely to be usable in
different classes
-
-
-
Reduce number of arguments by:
-
-
- Breaking a message into several smaller messages
-
-
- Creating a new class that represents a group of arguments
Rules for Finding Standard Protocols
* Eliminate case analysis
- Checking class of an object
if (anObject class = integer) then
anObject.Foo;
else
anObject.Fee;
Implement Foo in all relevant classes to perform the equivalent operation
anObject.Foo
- Case analysis of values of variables
Can be more difficult, but no less important
Rules for Finding Standard Protocols
* Recursion introduction
- If an operation X is implemented by performing a similar operation on the
component of the receiver, then that operation should also be named X.
-
void OrderedLinkedList::add(int value)
{
cell *newCell;
newCell = new cell;
newCell->value = value;
listHead->add(*newCell);
};
Abstract Class
A class which is not used to create objects
Used to collect behavior common to a set of classes, that is, abstract classes
are used to define standard protocol
Defines the essential nature of its subclasses
Abstract classes are abstractions
Abstractions are more likely to be used in other projects
Abstract classes list their protocol, but may not implement all operations in
the protocol
Often abstract classes don't define any state
Rules for Finding Abstract Classes
* Avoid shallow class hierarchies
- A well-developed class hierarchy should be several layers deep
-
-
-
-
-
-
-
Rules for Finding Abstract Classes
* The top of the class hierarchy should be abstract
* Minimize access to variables
- One of the main differences between abstract and concrete classes is the
presence of data representation
-
- Classes can be made more abstract by eliminating their dependence on their
data representation
-
- Access state through messages
-
* Subclasses should be specializations
- Use is-a relation to determine subclasses
-
- Making concrete subclasses of an abstract class is a special case of
specialization
-
- Specialization test
Can the subclass be used anywhere the superclass is used?
Frameworks
Collection of abstract classes used to express a design for a particular kind
of application
Describes the components of the design and how they interact
Examples:
- MacApp is a framework for Macintosh applications
-
- The Smalltalk Model/View/Controller (MVC) is a framework for constructing
Smalltalk user interfaces
Rules for Finding Frameworks
Large classes are frequently broken into several small classes as they grow,
leading to a new framework
A collection of small classes can be easier to learn and will always be easier
to reuse than a single large class
A collection of class hierarchies provides the ability to mix and match
components while a single class does not
* Split large classes
- If a class has 50 to 100 operations then it must represent a complicated
abstraction. It is likely that such a class is not well defined and probably
consists of several different abstractions.
-
- Large classes should be viewed with suspicion and held guilty of poor
design until proven innocent.
-
Rules for Finding Frameworks
* Factor implementation differences into subcomponents
- If some subclasses implement a method one way and others implement it
another way, then the implementation of that method is independent of the
superclass. The method is likely to belong to a component of the
class.
Rules for Finding Frameworks
* Separate methods that do not communicate
- If half of the methods access half the state and the other half of the
methods access the rest of the state, then the class should be split
Rules for Finding Frameworks
* Reduce implicit parameter passing
- State can be used for parameter passing - don't do it
class Example
{
float temp;
void good(float news)
{
System.out.println( news + 5);
}
void test(float data)
{
temp = data;
stinko();
good(data);
};
void stinko()
{
System.out.println( temp + 5);
};
};