Lecture Notes on Object-Oriented Programming

OO Development Process

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

Booch identifies a macro process that organizes an entire team's activities over the course (weeks, months) of development. These are the same sort of good software engineering principles and management techniques that are already practiced.

The micro process is more interesting to us, since it it tailored to OO development. The micro process is iterative. It also emphasizes the interface and relationships between classes and objects over the implementation of specific methods in a class. We iterate over the four steps of the micro process as we proceed through the broader phases of Analysis, Design and Implementation.

The Micro Process

Identify Classes & Objects

This is the OOA stage. We define the problem, identify what is and what is not part of our problem domain (abstraction).

The output of this stage is a data dictionary containing all the key elements of the problem. Data dictionaries have advantages over just maintaining a list of things that will are in the problem domain. These are:

  • common and consistent vocabulary
  • supports project browing (good for new team members)
  • gives a global view of the project

Some sort of technique (CRC cards, drawing tool, CASE tool) is helpful here to represent each thing in the data dictionary.

Class & Object Semantics

We proceed with our list of things from the first step and develop the semantics (what our abstractions encapsulate and what they can do) of our classes and objects.

From this step we end up with interface files for our classes (.h files for C++).

This stage is where the "two heads are better than one" truism is seen most clearly. Debate sharpens the semantics of classes and improves them. The best ideas survive, the weak ones are reformulated.

Debates about class semantics and names can become heated. My theory is that since OO involves significant anthropomorphism, designers become more attached to their points-of-view.

Class & Object Relationships

We formalize in our diagrams the relationships between classes and objects. Associations are between classes. We look at groups of related classes and work on the diagrams to represent how they associate with each other.

Collaborations are more the concern of the design phase and deal with object diagrams and how objects collaborate.

Implementing Classes & Objects

Initially (in analysis) we do just enough of this to help show gaps and lacks with the design. Eventually the implementation becomes more and more "real". Iterations at this phase are consistent with the idea of working complex systems evolving from working simple systems.