Qualities Patterns Share: Robust Encapsulation

Much of the literature on object orientation defines encapsulation as “data hiding.” While this is true, it is far too limited as a definition. Data hiding is encapsulation. Not all encapsulation is data hiding.

Encapsulation is the hiding of anything. Here are some examples:

• Interfaces, abstract classes, and concrete base classes can be used to hide the types of classes that implement or derive from them, by casting.
• Factories can encapsulate the specific design of a subsystem; clients call the factory but do not couple to the specific details of what is built.
• The number of entities in a collaboration (cardinality) can be hidden. All clients see a single interaction when, in fact, there may be more.
• Workflows and the details of interactions that vary by circumstance can be hidden.
• Whether an instance is shared or not can be hidden.

Whenever something can be hidden, you gain advantages if you have to change it. You have much greater freedom when you can make a change without extensively investigating the system, without fear that you may introduce a defect, and without, in fact, creating one.

What you hide you can freely change. Each pattern hides different things from the rest of the system.