Encapsulation is one of the most misunderstood aspects of object-oriented programming. Most people seem to think that the related concept of information hiding simply means that private fields should be exposed by public properties (or getter/setter methods in languages that don’t have native properties).

Have you ever wondered what’s the real benefit to be derived from code like the following?

private string name;

public string Name

{

    get { return this.name; }

    set { this.name = value; }

}

This feels awfully much like redundant code to me (and automatic properties are not the answer – it’s just a compiler trick that still creates private backing fields). No information is actually hidden. Derick Bailey has a good piece on why this view of encapsulation is too narrow, so I’m not going to reiterate all his points here.

So then what is encapsulation?

The whole point of object-orientation is to produce cohesive pieces of code (classes) that solve given problems once and for all, so that programmers can use those classes without having to learn about the intricate details of the implementations.

This is what encapsulation is all about: exposing a solution to a problem without requiring the consumer to fully understand the problem domain.

This is what all well-designed classes do.

• You don’t have to know the intricate details of TDS to use ADO.NET against SQL Server.
• You don’t have to know the intricate details of painting on the screen to use WPF or Windows Forms.
• You don’t have to know the intricate details of Reflection to use a DI Container.
• You don’t have to know how to efficiently sort a list in order to efficiently sort a list in .NET.
• Etc.

What makes encapsulation so important is exactly this trait. The class must hide the information it encapsulates in order to protect it against ‘naïve’ users. Wikipedia has this to say:

Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state.

Keep in mind that users are expected to not fully understand the internal implementation of a class. This makes it obvious what encapsulation is really about:

Encapsulation is a fail-safe mechanism.

By corollary, encapsulation does not mean hiding complexity. Whenever complexity is hidden (as is the case for Providers) feedback time increases. Rapid feedback is much preferred, so delaying feedback is not desirable if it can be avoided.

Encapsulation is not about hiding complexity, but conversely exposing complexity in a fail-safe manner.

In Lean this is known as Poka-yoke, so I find it only fitting to think about encapsulation as Poka-yoke Design: APIs that make it as hard as possible to do the wrong thing. Considering that compilation is the cheapest feedback mechanism, it’s preferable to design APIs so that the code can only compile when classes are used correctly.

In a series of blog posts I will look at various design smells that break encapsulation, as well as provide guidance on how to improve the design to make it safer, thus going from smell to fragrance.

1. Design Smell: Temporal Coupling
2. Design Smell: Primitive Obsession
3. Code Smell: Automatic Property
4. Design Smell: Redundant Required Attribute
5. Design Smell: Default Constructor

Postscript: At the Boundaries, Applications are Not Object-Oriented