Lecture Notes on Object-Oriented Programming

Encapsulation

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

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.