Lecture Notes on Object-Oriented Programming

Review of OO 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


The active elements of an OO program. Objects are of a definite type (their class, and possibly some other interface) and have two parts: what they know (attributes) and what they can do (behavior). They occupy memory, they get work done, they have a unique id.


The templates from which objects can be instantiated. The definition of the class determines what objects of that class can know and do. Classes themselves are passive (compared to objects at least, and if you ignore class members).


The idea that an object encapsulates knowledge and behavior. We control what outsiders may see with access control. Generally, the internal state of an object is hidden from other objects. The algorithms used in the definition of the class methods are hidden by the class.

Includes the idea of containment as an essential relationship between classes.


Classes may be related to each other in an inheritance hierarchy. Top level, abstract classes tend not to be instantiated into active, living, breathing objects. They serve to gather together the common attributes and behavior which their concrete subclasses inherit.


Messages are what gets work done in an OO system. There are four parts to a message: a receiver object, a method name, optional method arguments, and an optional return value.


Objects must have a unique identity, knowledge of which is required to send an object a message. Pointers give us aliases for the unique names of objects, and confuse the issue of identity.


The idea that the code that is executed as the result of a message being sent depends on the class of the object that receives the message. Objects of different classes can react differently to being sent the same method in a message.


What determines the capabilities or behavior of a thing, such as an object. Distinct from, but often confused with, class. Type is equivalent to the interface of a class. Programming to types, not classes, maintains flexibility.