Lecture Notes on Object-Oriented Programming


This collection of notes on OOP was never meant to stand alone. It also represents a view of OO circa early to mid 1990s. Some people still find them useful, so here they are, caveat emptor. Special thanks to Gilbert Benabou for taking to time to compile the first printable version of this document and inspiring us to provide it.

[ PDF ] Printable Version

Table of Contents
  1. Introduction: Motivation for OO
  2. The OO Paradigm
  3. Visualizing Program Execution
  4. Naming Conventions
  5. The Object Model
  6. Abstraction and Identity
  7. Messaging
  8. Encapsulation & Modularity
  9. Hierarchy
  10. Object-Oriented Typing
  11. OO Concurrency & Persistence
  12. OO Development Process
  13. OO Analysis Techniques
  14. Pitfalls in OO Analysis
  15. UML Notation
  16. CRC Cards
  17. OO Class Relationships
  18. Object Oriented Aggregation
  19. Object Oriented Interitance
  20. Other Object Oriented Class Relationships
  21. Object Oriented Instantiation
  22. Object Oriented Polymorphism
  23. Review of OO Programming
  24. The Quality of Classes and OO Design

We group our abstractions (classes) into a hierarchy to keep them organized (inheritance structure).

Is-a hierarchy

The "is a" hierarchy defines classes like this: "a dog is a mammal", "an apple growing plan is a fruit growing plan which is a growing plan". This is the test to apply if you are not sure whether there is a classical inheritance relationship between classes.

class FruitGrowingPlan isa GrowingPlan {
class AppleGrowingPlan isa FruitGrowingPlan {

As we form the class hierarchy, we push the common state and behavior between lower level classes into the upper level classes. This allows for the lower level classes (which are usually "discovered" first in an OOA) to be built on top of the higher level classes, thus making them smaller and more readily understandable.

This activity (pushing commonality up the inheritance hierarchy) makes for a generalization/specialization hierarchy. The classes at the top are more general (or abstract) and the classes at the bottom are more specific (or concrete). It is usually the concrete classes that we instantiate objects from.

Abstract classes are simply that; abstract means of organizing shared information.

Forming the hierarchy eliminates redundant code and organizes our abstractions into something easier to understand.

The "isa" hierarchy is a compile-time hierarchy, in that it involves classes extending other classes.

Part-of hierarchy

The other type of hierarchy is the "part of" hierarchy we find in our designs. This is hierarchy through aggregation.

Objects would be overly large if it was not possible to aggregate them. For example, a Graph object quite naturally contains a List of nodes in the graph. Without this ability, the List class would have to be duplicated in Graph.

The "hasa" hierarchy is another means of code organization.

The "hasa" hierarchy is a run-time hierarchy, in that it involves objects containing other objects.