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
We encapsulate the details of a class inside its private part so that it is impossible (and not just suggested) for any of the class's clients to know about or depend upon these details.
The ability to change the representation of an abstraction (data structures, algorithms) without disturbing any of its clients is the essential benefit of encapsulation.
Aside - should I say the "class's clients" or the "object's clients"?
Why encapsulate and hide?
- You can delay the resolution of the details until after the design.
- You can change it later without a ripple effect.
- It keeps your code modular.
How we do this separation is with two separate pieces for each class, an implementation and an interface.
Modularity is closely tied with encapsulation; think of modularity as a way of mapping encapsulated abstractions into real, physical modules.
The C/C++ convention is to create two files for each class: a header file (.h suffix) for the class interface, and an implementation file (.c, .cp, .cpp, .C suffix) for the code of the class.
Booch gives two goals for defining modules. Make a module cohesive (shared data structures, similar classes) with an interface that allows for minimal inter-module coupling.
Other considerations: team work, security, documentation.
Important to remember that the decisions concerning modularity are more physical issues, whereas the encapsulation of abstractions are logical issues of design.
It is possible to "over modularize". This can increase documentation costs and make it hard to find information.