 |
CS 635: Advanced Object-Oriented Design & Programming |
|
|---|
Spring Semester, 1998
Intro Lecture
To Lecture Notes Index
© 1998, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 21-Apr-98
Contents of Doc 1, Intro Lecture
- References
- Reading Assignment
- Introduction
- Meyer's Criteria for Evaluating for Modularity
- Decomposability
- Composability
- Understandability
- Continuity
- Protection
- Principles for Software Development
- What is Object-Oriented Programming
- Language Level Definition of OOP
- Conceptual Level Definition of OOP
- Abstraction
- Encapsulation
- Information Hiding
- Hierarchy
- Some Heuristics
- Multiple Inheritance
- Single Inheritance
- Metrics Rules of Thumb2
Object-Oriented Software Construction, Bertrand Meyer, Prentice Hall,
1988
Object-Oriented Design Heuristics, Arthur Riel, Addison-Wesley, 1996
Start reading the sections on coupling (pages 72-86, 92-111) of Object Coupling
and Object Cohesion, chapter 7 of Essays on Object-Oriented Software
Engineering, Vol 1, Berard, Prentice-Hall, 1993.
Pages 72-86 will take a lecture to cover.
Decompose problem into smaller subproblems
that can be solved separately
Example: Top-Down Design
Counter-example: Initialization Module
Meyer's Criteria for Evaluating for Modularity
Freely combine modules to produce new systems
Examples: Math libraries
Unix command & pipes
Meyer's Criteria for Evaluating for Modularity
Individual modules understandable by human reader
Counter-example: Sequential Dependencies
Meyer's Criteria for Evaluating for Modularity
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 Criteria for Evaluating for Modularity
Effects of an abnormal run-time condition is confined to a few modules
Example: Validating input at source
KISS Keep it simple, stupid
Supports:
-
- Understandablity
- Composability
Decomposability
Small is Beautiful
Upper bound for average size of an operation[1]
| Language | Lines of Code |
| Smalltalk | 8 |
| C++ | 24 |
Supports:
- Decomposability
- Composability
- Understandability
Applications of Principles
First program:
class HelloWorldExample
{
public static void main( String args[] )
{
System.out.println( "Hello World" );
}
}
Grow programs
- Start with working program
-
- Add small pieces of code and debug
-
-
Language Level Definition
Conceptual Level Definition
Object
Language Level Definition of OOP
Class
Language Level Definition of OOP
Inheritance
"Extracting the essential details about an item or group of items, while
ignoring the unessential details."
Edward Berard
"The process of identifying common patterns that have systematic variations; an
abstraction represents the common pattern and provides a means for specifying
which variation to use."
Richard Gabriel
Example
Pattern: Priority queue
Essential Details: length
items in queue
operations to add/remove/find item
Variation: link list vs. array implementation
stack, queue
Conceptual Level Definition of OOP
Enclosing all parts of an abstraction within a container
Example
Conceptual Level Definition of OOP
Hiding parts of the abstraction
Example
Conceptual Level Definition of OOP
Abstractions arranged in order of rank or level
Class Hierarchy
Conceptual Level Definition of OOP
Hierarchy
Object Hierarchy
A class should capture one and only one abstraction
- Class = abstraction
Keep related data and behavior in one place
- An abstraction is both data and behavior (methods)
All data should be hidden within its class
-
- Information hiding
Heuristics Continued
Beware of classes that have many accessor methods defined in their public
interface. Having many implies that related data and behavior is not being
kept in one place.
class test
{
private int thisData;
private int thatData;
private float moreData;
public void setThisData( int data ) { thisData = data; }
public void setThatData( int data ) { thatData= data; }
public void setMoreData( int data ) { moreData= data; }
public void getThisData( ) { return thisData; }
public void getThatData( ) { return thatData; }
public void getMoreData( ) { return moreData; }
public String toString() { // code deleted }
}
No work is being done in this class.
Other classes are getting the data in class test and performing some operation
on it.
Why is this class not doing the work on the data!
Who is doing the work?
The God Class Problem
Distribute system intelligence horizontally as uniformly as possible, that is,
the top-level classes in a design should share the work uniformly.
Do not create god classes/objects in your system. Be very suspicious of a class
whose name contains Driver, Manager, System, or
Subsystem
Beware of classes that have too much noncommunicating behavior, that is,
methods that operate on a subset of the data members of a class. God classes
often exhibit much noncommunicating behavior.
Divide noncommunicating behavior into separate classes
The God Class Problem - Data Form
Legacy Non-OO System
Poor Migration to OO System
Proliferation of Classes Problem
Be sure that the abstractions that you model are classes and not simply roles
object play
Do we use a Father class, Mother Class, and a Child class to model a family?
Or do we use a Person class, with Person objects acting as Father, Mother and
Child?
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 ( i.e. do not
count sets, gets, prints).
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
Parent classes should not know anything about their child (and grandchild,
etc.) classes.
All data in a parent class should be private to the child class
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
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 (fields, data members) 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
visitors since 26-Jan-98