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

References


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

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

Reading

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

Introduction

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

Java
Self
Python
Perl
Prograph
Modula 3
Oberon
Scheme
Smalltalk Venders
ParcPlace, IBM, Quasar, Disney
Prolog++
Ada 95
Object Pascal (Delphi)
Object X, X = Fortran, Cobol, etc. 

Doc 1, Intro Lecture Slide # 4

Methodologies


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

Fusion

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

Decomposability


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

Composability


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

Understandability


Individual modules understandable by human reader

Counter-example: Sequential Dependencies 




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

Continuity


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

Protection


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

Supports:
Understandablity
Composability
Decomposability


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
Smalltalk8
C++24


Supports:

Decomposability
Composability
Understandability

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

Abstraction


“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

Doc 1, Intro Lecture Slide # 16

Encapsulation


Enclosing all parts of an abstraction within a container


Information Hiding



Hiding parts of the abstraction 


Doc 1, Intro Lecture Slide # 17

Class & Object


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

Object
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;
   }
}
Objects 
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

Examples

Language
Access levels available for

Methods
 Fields
C++
 Public, protected, private
Public, protected, private
Java
 Public, protected, private, package
Public, protected, private, package
Smalltalk
 Public
 Private


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

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

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

Parent test = getAParentOrChildObject();
test.foo();

Doc 1, Intro Lecture Slide # 22

Polymorphism and C++

See http://www.eli.sdsu.edu/courses/fall95/cs596_1/notes/Poly/Poly.html for a more complete example of polymorphism and C++ 

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

Parent*  test = getAPointerToAParentOrChildObject();
test->foo();

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


Customer

Transaction

Currency



Doc 1, Intro Lecture Slide # 25
Account 

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 );
      else
         // report the problem. Code not shown
   }
   
   protected abstract boolean validateTransaction( Transaction 
                                       accountActivity 
                                      );
   protected abstract void commitTransaction( Transaction 
                                      accountActivity 
                                    );
   // other methods left out
}

Doc 1, Intro Lecture Slide # 26
Account Class Inheritance 

Doc 1, Intro Lecture Slide # 27
Polymorphism 

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 );

Supports:

Composability
Continuity
 


Doc 1, Intro Lecture Slide # 29

Stages of Object-Oriented Expertise

From Object-Oriented Software Development: A Practical Guide

Novice

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."


Apprentice

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

Journeyman

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."


Guru

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