SDSU CS 535 Object-Oriented Programming & Design
Spring Semester, 1999
Intro Lecture
    Lecture Notes Index    Next    
© 1999, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 26-Jan-99

Contents of Doc 1, Intro Lecture


Object-Oriented Software Construction , Bertrand Meyer, Prentice Hall, 1988

Object-Oriented Software Development: A Practical Guide, Mark Lorenz, Prentice Hall, 1993


Chapters 1-2 of Designing Object-Oriented Software, Tuesday January 26, 1999.

Start Chapter 7 of Object Coupling and Object Cohesion by Thursday, January 28, 1999

Doc 1, Intro Lecture Slide # 2


History and Languages

1967 Simula

1970 to 1983 Smalltalk

1979 Common LISP Object System

1980 Stroustrup starts on C++

1981 Byte Smalltalk issue

1983 Objective C

1986 C++

1987 Actor, Eiffel

1991 C++ release 3.0

199x Volume of OO books/articles
deforests Oregon

1995 Design Patterns

1996 Java

1983 to 1989 Language books with OO concepts

1989 to 1992 Object-oriented design books

1992 to present Object-oriented methodology books

Doc 1, Intro Lecture Slide # 3
Other Languages

Modula 3
Smalltalk Venders
ParcPlace, IBM, Quasar, Disney
Ada 95
Object Pascal (Delphi)
Object X, X = Fortran, Cobol, etc.

Doc 1, Intro Lecture Slide # 4


Approach to developing software

Methodologies encompass
Step-by-step methods
Graphical notation
Documentation techniques
Principles, guidelines, policies
Object-Oriented Design (OOD) Booch

Object-Oriented Systems Analysis (OOSA) Shlaer & Mellor

Object Modeling Technique (OMT) Rumbaugh et al.

Object-Oriented Analysis (OOA) Coad & Yourdon
Hierarchical Object Oriented Design (HOOD) European Space Agency, HOOD Working Group

Responsibility-Driven Design (CRC) Wirfs-Brock et al.

Object-Oriented Software Engineering (Objectory) Jacobson


UML – Unified Modeling Language Booch, Jacobson, Rumbaugh

Doc 1, Intro Lecture Slide # 5
Goal of the Course

Producing good objects

Doc 1, Intro Lecture Slide # 6

Meyer's Criteria for Evaluating for Modularity


Decompose problem into smaller subproblems
that can be solved separately

Example: Top-Down Design

Counter-example: Initialization Module

Doc 1, Intro Lecture Slide # 7
Meyer's Criteria for Evaluating for Modularity


Freely combine modules to produce new systems

Examples: Math libraries
Unix command & pipes

Doc 1, Intro Lecture Slide # 8
Meyer's Criteria for Evaluating for Modularity


Individual modules understandable by human reader

Counter-example: Sequential Dependencies

Doc 1, Intro Lecture Slide # 9
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

Doc 1, Intro Lecture Slide # 10
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

Doc 1, Intro Lecture Slide # 11

Principles for Software Development

KISS Keep it simple, stupid


Doc 1, Intro Lecture Slide # 12
Small is Beautiful
See page 185 of Object-Oriented Software Development: A Practical Guide more information about these guidelines.

Upper bound for average size of an operation

LanguageLines of Code



Doc 1, Intro Lecture Slide # 13
Applications of Principles

First program:

   class HelloWorldExample 
      public static void main( String args[] ) 
         System.out.println( "Hello World" );

Doc 1, Intro Lecture Slide # 14

Objects and Other Basics

Major Concepts

Doc 1, Intro Lecture Slide # 15


“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 1, Intro Lecture Slide # 16


Enclosing all parts of an abstraction within a container

Information Hiding

Hiding parts of the abstraction

Doc 1, Intro Lecture Slide # 17

Class & Object

Encapsulates a single abstraction
Uses information hiding to insure only the relevant parts of the abstraction are visible

An instance of a class
Represents a particular instance of the abstraction

Doc 1, Intro Lecture Slide # 18
Class & Object Example
class Stack  {
   private float[] elements;
   private int topOfStack = -1;
   public Stack( int stackSize )  {
      elements = new float[ stackSize ];
   public void push( float item )  {
      elements[ ++topOfStack ] = item;
   public float pop()  {
      return elements[ topOfStack-- ];
   public boolean isEmpty()  {
      if ( topOfStack < 0 )    return true;
      else               return false;
   public boolean isFull()  {
      if ( topOfStack >= elements.length )    return true;
      else                           return false;
Stack me = new Stack( 20 );
Stack you = new Stack( 200 );
me.push( 5 );
you.push( 12 );
System.out.println( me.pop() );

Doc 1, Intro Lecture Slide # 19
Design (Conceptual) and Language Level Classes

Each object-oriented language has a class language construct

Features of this construct vary among languages


Access levels available for

Public, protected, private
Public, protected, private
Public, protected, private, package
Public, protected, private, package

Design Level

At the design level a class will be an abstraction

This abstraction will be represented by:

The public interface of the abstraction (operations)
The data of the abstraction (information)

Doc 1, Intro Lecture Slide # 20
Example of the Class Construct without Abstraction

class StackData
   private  float[]  elements = new float[100];
   private  int        topOfStack      = -1;
   public int getTopOfStack()
      return topOfStack;
   public void setTopOfStack( int newTop )
      topOfStack = newTop;
   public float getElement( int elementIndex )
      return elements[ elementIndex ];
   public void setElement( int elementIndex, float element )
      elements[ elementIndex ] = element;

Doc 1, Intro Lecture Slide # 21


Polymorphism is the ability of instances of two or more classes to respond to the same message

In languages like Java and C++, inheritance (or implementation of interfaces) is required to use polymorphism

public class Parent{
   public void foo() {
      System.out.println( "Parent foo" );
   public void bar(){
      System.out.println( "Parent bar" );
public class ChildFoo extends Parent{
   public void foo(){
      System.out.println( "ChildFoo foo" );
public class ChildBar extends Parent{
   public void bar(){
      System.out.println( "ChildBar bar" );
What Output is Possible Here?

Parent test = getAParentOrChildObject();;

Doc 1, Intro Lecture Slide # 22

Polymorphism and C++

See for a more complete example of polymorphism and C++

#include <iostream.h>
class  Parent {
   void virtual foo();
   void virtual bar();
void Parent::foo() {
   cout << "Parent foo" << endl;
void Parent::bar() { cout << "Parent bar" << endl; }
class ChildFoo : public Parent {
   void virtual foo();
void ChildFoo::foo() {
   cout << "ChildFoo foo" << endl;
class ChildBar : public Parent {
   void virtual bar();
void ChildBar::bar() { cout << "ChildBar bar" << endl; }
What Output is Possible Here?

Parent*  test = getAPointerToAParentOrChildObject();

Doc 1, Intro Lecture Slide # 23

Simplistic Example

Last Federal Virtual Bank wants its entire banking software redone in Java, so it can shut down its branch offices and perform all its business via the WWW.

Customer records include the customers name, address, personal information, passwords, etc. and accounts.

The bank offers various types of accounts: checking, savings, CD, Junior savings accounts.

Bank officers will introduce new types of accounts from time to time.

Checking account charge 12 cents/check unless the average account balance for the month is greater than $1,000. The first three ATM transactions per month are free. Additional ATM transactions cost 50 cents.

All transactions over $1,000 dollars must be reported to the federal government.

Junior savings accounts are for children under the age of 13. Children can deposit any amount into the account. Deposits of over $100 are reported to their parents. Children can withdrawal up to $10 from the account. Individual withdrawals over $10 must be verified by a parent. Total withdrawals over $100 per month are reported to the parents.

Transactions include time & date, amount, location, type of transaction, account number and teller.

Doc 1, Intro Lecture Slide # 24

Banking Classes




Doc 1, Intro Lecture Slide # 25

abstract class account {
   public static final boolean VALID = true;
   protected Customer accountOwner;
   protected Currency   balance;
   protected Stack accountHistory;
   // Other fields left out
   public void processTransaction( Transaction accountActivity ) {
      if ( validateTransaction( accountActivity ) == VALID )
         commitTransaction( accountActivity );
         // report the problem. Code not shown
   protected abstract boolean validateTransaction( Transaction 
   protected abstract void commitTransaction( Transaction 
   // other methods left out

Doc 1, Intro Lecture Slide # 26
Account Class Inheritance

Doc 1, Intro Lecture Slide # 27

Account  newCustomer;
newCustomer = magicFunctionToCreateNewAccount()
newCustomer.processTransaction( amount );
Which processTransaction is called?

Adding new types of accounts to program requires:

Adding new subclasses
Changing code that creates objects

Doc 1, Intro Lecture Slide # 28
Modular Design Rule

Avoid Case (and if) Statements

switch  (  newCustomer.accountType ) {
   case SAVINGS:
      // Code to process Savings account
   case CD:
      // Code to process CD account
   case CHECKING:
      // Code to process Checking account
   // etc.
Use Polymorphism
newCustomer.processTransaction( amount );



Doc 1, Intro Lecture Slide # 29

Stages of Object-Oriented Expertise

From Object-Oriented Software Development: A Practical Guide


Duration: 3 to 6 months

"Novices spend their time trying to get their function-oriented heads turned around, so they can see the application object classes. They have a hard time finding the classes and write a lot of function-oriented code."


Duration: 3 to 6 months

"Apprentices begin to understand what object-orientation really means. They still prefer to work with others, who help foster an environment of discovery. Apprentices begin turning out good designs, although not consistently. Gurus and journeymen still need to keep an eye on apprentices."

Doc 1, Intro Lecture Slide # 30
Stages of Object-Oriented Expertise


Duration: varies greatly, a least a year

"Journeyman have internalized the OO paradigm and work independently. They can provide key inputs during the design reviews. They still have mental roadblocks that may require a guru to break through."


Duration: lifetime

"For gurus, OO development comes naturally. A guru automatically sees things in an OO perspective, moving quickly through the phases of development during rapid iterations. A guru can move the project over mental hurdles, causing others to see something clearly that eluded them before."

"There are very few gurus in the world today. The rest of us will have to rely on proven processes and methodologies."

"I've yet to see someone successfully make it past the novice stage and even consider thinking about software in other than OO terms."

Copyright © 1999 SDSU & Roger Whitney, 5500 Campanile Drive, San Diego, CA 92182-7700 USA.
All rights reserved.

    visitors since 26-Jan-99    Next