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 but 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 the 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.

This is Scott Bain. Visit us at www.netobjectives.com.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.