Lecture Notes on Object-Oriented Programming

Pitfalls in OO Analysis

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

Underestimating the need for and difficulty of analysis

Time and money pressures from managers, and the natural tendency of developers to "go to code" quickly, can be a bad combination. Analysis is expensive in time and money, and takes a lot of skill, both in the domain of the problem, and in the OO domain. There is much to consider about each abstraction: the static and dynamic models, the invariants, quality of abstraction, potential for re-use. There are design issues, driven partly by language choice: implementing the abstraction, life cycle issues, safe-use issues, documenting proper use.

Accurate and complete requirement specifications

Except for very constrained domains, re-implementations of existing functionality, or trivial applications, the process of defining requirements is almost guaranteed to result in:

  • incomplete specifications
  • incorrect specifications

A study in 1999 by Elemer Magaziner of requirement specifications found that they are typically only 7% complete and 15% correct.

Another almost guaranteed phenomenon is that they will change over time as the project progresses.

Given the cost of change over a project's lifecycle this is a huge problem and argues for alternatives to what the above pitfall seems to argue for (lots of upfront analysis).

Building a too-general solution

Generality is good, but comes at a cost. Some balance must be met. Developers who really become OO are particularly prone to this problem. The elegant, complete, general solution to a class design becomes a goal unto itself. You've got to know when good is good enough.

The wrong number of architects

Encapsulation and interface doesn't mean you can split your problem into pieces, give each piece to a team, then never talk across teams only to get back together and expect everything to "just work". There are aspects of class design that don't show up in the interface files, or in the documentation. Someone (or a small team of someones) has to have chief responsibility for the architecture of large projects.

Re-architecting too often or too little

Developers enamored with the beauty and elegance of a design may want to re-architect when something new throws their model for a loop. This is possible, and a big advantage of OO, if done properly, but can be taken too far (re-architecting for its own sake, or for the intellectual challenge). At the same time, you must occassionally face facts and re-think your architecture if you find it growing too complex, hard to understand, full of hacks, etc.