University of Calgary
mail toRob Kremer

Object Orientation

Lecture Notes on

Abadi, M. & Cardelli, L. (1996). A Theory of Objects. New York, Springer.  Chapter 1: "Object Orientation."

CPSC 701.01 Object Theory
Table of Contents
Objects
Analogy
 The object-oriented approach is based on the analogy: 
model of a physical system back to previous pageforward to next pagesoftware simulation of the model
  • The physical system is composed of objects
  • The model of the physical system is composed of objects too, but we may need more objects that don't actually exist in the physical system.
  • The software system can be composed of analogous "objects" that represent the objects in the model of the physical system
 
Mechanical
Model
Building a mechanical model of a physical system involves: 
  • Analysis
  • Design
  • Implementation
 
Example
Mechanical model of the solar system: 
  • Analysis: Planets move along precise orbits
  • Design: Finding a mechanism to move spheres along "orbits"
  • Implementation: Preparing and assembling spheres, gears, and springs.
 
OO model
In modeling the solar system example in software, one generaly conceives of the orbits as objects, as they are in the mechanical model.  But orbits are clearly not objects in the real-world system. 
Origins
The OO approach (arguable) arises from Simula, which was original specialized for simulation.  But the approach generalizes.
Properties
The broad applicability of the OO approach may be attributed to: 
  • The analogy between software and physical models
  • The resilience of the software models
  • The reuseability of the components of the software models

Applies to
Also addressed by
Analogy
 Analysis: Analogy between the physical model and the software model has proved very useful.
  • algorithms
  • data structures
    		•
    Resilience
    		 Design: Objects form natural abstraction boundaries (focus on structure instead of algorithms.  Algorithms are factored into methods.
  • Abstract Data Types (ADTs)
    		•
    Reusability
    		 Implementation: Natural organization of objects into hierarchies encourages reuse of objects at the high end of the hierarchy.
  • modularization
  • parameterization
    		•

     
    Reuse
    Claim
    		 Object-oriented languages support reuse of components better than traditional programming languages 
    Reuse
    		A software component is reusable if it can be used in more than one context. 

    Examples: 

    • importing modules
    • instatiating a generic module with different parameters
     
    Replacement
    		Reuse is by replacement. 
    • In traditional languages replacement (reuse) requires exact agreement in type or interface. 
    • In OO languages require only appoximate agreement is required.
     
    Kinds of
    Replacement
    		In OO languages, there are two distinct kinds of replacement (reuse): 
    • Object replace other objects
    • Methods replace other methods
     
    Replacing
    Objects
    		One object may be replaced by another if the replacing object has at least the same set of attributes. 
    Replacing
    Methods
    		Two types: 
    • Overriding: replacement of methods in a superclass
      • Overriding method must conform to the interface of old one (flexibly)
      • New method may be more specific
    • Inheritance: reusing existing methods
     
    Self
    		The concept of self is required so that a method may refer to its host object (and therefore, its sibling methods). 
    • Sibling methods may change through inheritance and overriding.
    • A strictly inherited method may have new behaviour in a derived object because it may call sibling methods which are overridden in the derived object.
     
    The University of Calgary
    		  
    Up to page above
    up
    		 forward to next page 
    forward

    mail toRob Kremer
    Last Modified Aug 15, 2005
    CPSC 701.01 Object Theory
     Graduate Course in Software Engineering