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
- Introduction: Motivation for OO
- The OO Paradigm
- Visualizing Program Execution
- Naming Conventions
- The Object Model
- Abstraction and Identity
- Encapsulation & Modularity
- Object-Oriented Typing
- OO Concurrency & Persistence
- OO Development Process
- OO Analysis Techniques
- Pitfalls in OO Analysis
- UML Notation
- CRC Cards
- OO Class Relationships
- Object Oriented Aggregation
- Object Oriented Interitance
- Other Object Oriented Class Relationships
- Object Oriented Instantiation
- Object Oriented Polymorphism
- Review of OO Programming
- 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.