SDSU CS 535 Object-Oriented Programming
Spring Semester, 2003
Some OO Terms
Previous    Lecture Notes Index    Next    
© 2003, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 03-Mar-03

Contents of Doc 11, Some OO Terms


Ralph Johnson Lecture notes, Lecture 3 Data Abstraction and Encapsulation,

Object-Oriented Design Heuristics, Riel, Chapter 2

Doc 11, Some OO Terms Slide # 2

Some OO Terms

Doc 11, Some OO Terms Slide # 3


“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


Pattern:    Priority queue
Essential Details:   length 
   items in queue 
   operations to add/remove/find item
Variation:   link list vs. array implementation
   stack, queue

Doc 11, Some OO Terms Slide # 4
Heuristic 2.8

A class should capture one and only one key abstraction

Key abstraction

Look at nouns in requirements specification system description

Doc 11, Some OO Terms Slide # 5


Enclosing all parts of an abstraction within a container

Class contains

Heuristic 2.9

Keep related data and behavior in one place

Code that uses a lot of accessing methods of an object should be used to that object

(aPoint x squared + aPoint y squared) sqrt


aPoint r

Doc 11, Some OO Terms Slide # 6

Information Hiding

An object should hide design decisions from its users


How does Point story its data?

How does OrderedCollection hold elements?

We use the classes without knowing

Doc 11, Some OO Terms Slide # 7
Heuristic 2.1

All data should be hidden within it class

Smalltalk instance variables in can be accessed in:

Most languages have a construct for global access to data

Doc 11, Some OO Terms Slide # 8
Engineering Heuristics, Absolutes & Beginners

All design decisions involve trade offs

Heuristics are design decisions that are nearly always true

No heuristic is correct all the time

Beginners violate heuristics because

Doc 11, Some OO Terms Slide # 9
Smalltalk and Private Methods

Private method

All instance methods in Smalltalk are publicly accessible

Put private methods in “private” protocol

Smalltalk programmers know not to use such methods

Doc 11, Some OO Terms Slide # 10
Two View of a Class: Inside & Outside

Users of a class care about

Doc 11, Some OO Terms Slide # 11


Strength of interaction between objects in system

How tangled together the classes are


Degree to which the tasks performed by a single module are functionally related

Doc 11, Some OO Terms Slide # 12

Ralph Johnson’s Suggestions for Finding Abstractions

Doc 11, Some OO Terms Slide # 13
Do One Thing

Method should do on thing


Class should be what its name says


Break complex classes/methods into simpler ones

Doc 11, Some OO Terms Slide # 14
Eliminate Duplication

(self asInteger - $a asInteger + anInteger) \\ 26 – (self asInteger - $a asInteger)

(self alphabetValue + anInteger) \\ 26 - self alphabetValue.

Doc 11, Some OO Terms Slide # 15
Keep rate of change similar

Doc 11, Some OO Terms Slide # 16
Minimize interfaces

Use the smallest interface you can

Use Number instead of Float

Avoid embedding classes in names

add: instead of addNumber:

Don’t check the class of an object

Doc 11, Some OO Terms Slide # 17
Minimize size of abstractions

Methods should be small

Classes should be small

VW 7.0 Base System

Variables / class
Methods / class
Carriage returns/method

Doc 11, Some OO Terms Slide # 18
Code used to generate Numbers

Variables Per Class

classes :=Smalltalk allClasses reject: [:each | each isMeta]
variablesInClass :=classes collect: [:each | each instVarNames size].
average :=((variablesInClass fold: [:sum :each | sum + each] )/ 
                  variablesInClass size) asFloat. 
mean := variablesInClass asSortedCollection at: variablesInClass size // 2.
max := variablesInClass fold: [:partialMax :each | partialMax max: each]

Methods Per Class

classes :=Smalltalk allClasses reject: [:each | each isMeta]
methodsInClass :=classes collect: [:each | each selectors size].
average :=((methodsInClass fold: [:sum :each | sum + each] )/ 
                  methodsInClass size) asFloat. 
mean := methodsInClass asSortedCollection at: methodsInClass size // 2.
max := methodsInClass fold: [:partialMax :each | partialMax max: each]

Doc 11, Some OO Terms Slide # 19
Minimize number of abstractions

 A class hierarchy 6-7 levels deep is hard to learn

Break large system into subsystems, so people only have to learn part of the system at a time

Doc 11, Some OO Terms Slide # 20


Objects with the same interface can be substituted for each other at run-time

Variables take on many classes of object

Objects will behave according to their type

Code can work with any object that has the right set of methods

In C++ polymorphism requires

In Java polymorphism requires

In Smalltalk polymorphism does not require inheritance

Doc 11, Some OO Terms Slide # 21

Counter>>printOn: aStream
      nextPutAll: ‘Counter(‘;
      nextPutAll: count printString;
      nextPutAll: ‘)’

aStream can be any object that implements nextPutAll:

Note we do not write:

Counter>>printOn: aStream
   aStream class = FileStream ifTrue:[ write to file ].
   aStream class = WriteStream ifTrue: [write to write stream]
   aStream class = TextCollector ifTrue: [write to Transcript]

Doc 11, Some OO Terms Slide # 22

Avoid Case Statements

Smalltalk has no case statement

OO programers send a message to object instead

Each type of object handles the message according to its type

Case statements make it harder to add new cases

Doc 11, Some OO Terms Slide # 23

Simplistic Example

Bank offers various types of accounts:

Each type has different rules for processing a transaction

Doc 11, Some OO Terms Slide # 24

Banking Classes




Doc 11, Some OO Terms Slide # 25
Processing a Transaction

Using Case Statment

newCustomer := Bank createNewAccount: type.


newCustomer class = Checking ifTrue:[ ...]
newCustomer class = Savings ifTrue:[ ...]
newCustomer class = CD ifTrue:[ ...]
newCustomer class = Jonior ifTrue:[ ...]

Doc 11, Some OO Terms Slide # 26

newCustomer := Bank createNewAccount: type.
newCustomer.processTransaction: amount

Which processTransaction is called?

Adding new types of accounts to program requires:

Adding new subclasses
Changing code that creates objects

Avoid checking the class of an object

Copyright ©, All rights reserved.
2003 SDSU & Roger Whitney, 5500 Campanile Drive, San Diego, CA 92182-7700 USA.
OpenContent license defines the copyright on this document.

Previous    visitors since 03-Mar-03    Next