The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

Encapsulation vs Abstraction, a blog post I wrote a few years ago, is the most popular post on this blog. So I decided to revisit the subject. This time, I want to focus more on encapsulation.

Encapsulation = Information Hiding

Did you get that?

Don’t worry. By the end of this post, you’ll get it.

If you did, you can probably stop reading this post. You already know what encapsulation is. Good for you!

I know McConnell in Code Complete 2 has a great focus on Object Oriented coding, so I turned to his book initially. And I found a great analogy for abstraction and encapsulation.

Encapsulation is a stronger concept than abstraction. Abstraction helps to manage complexity by providing models that allow you to ignore implementation details. Encapsulation is the enforcer that prevents you from looking at the details even if you want to. –Steve McConnell in Code Complete

This might sound confusing initially. Don’t worry. One thing to take away from it, though, is that encapsulation goes together with abstraction. In fact, McConnell says you cannot have just one, either you have both or you have none. I totally agree. There is no middle ground.

But this post is more about encapsulation…

The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules. –Joshua Bloch

Now we’re talking.

Mr. Bloch, another influential author, is basically telling you what encapsulation is: information hiding.

Once again, it’s a good analogy to have in your mind: Encapsulation = Information Hiding. That’s how you want to remember what encapsulation is.

On a practical level, how do you accomplish encapsulation? Steve McConnell, in in section 6.2 has some very good points:

• Minimize accessibility of classes and members
• Don’t expose member data in public
• Avoid putting private implementation details into a class’s interface
• Don’t make assumptions about the class’s users
• Avoid friend classes
• Watch for coupling that’s too tight

It’s also important that encapsulation not only applies to classes. It’s easy to only think of classes. But if also applies to object, package, namespace, class or interface.

Real World Example
I found another great definition in the book I started reading, Design Patterns by Lasater.

“Think of encapsulation like your mortgage company,” recommends Lasater.  You send of your mortgage payment every month and you get a statement back showing your loan data. Your mortgage company is hiding from you the accounting details. And you don’t really care, as long as your principle is decreasing after your payment is applied.

To take this a step further, here’s a class definition for the Mortgage payment. The idea of encapsulation is to only expose the necessary methods. Not more.

// taken from Design Patterns
class CustomerPayment {
  public double postPayment(int loanId, double payment) {
    // posts a payment
  }

  public List getAmortizedSchedule(int loanId) {
    // return a schedule in array
  }

There would be many more methods in the class. But they’re hidden. Hidden from the class interface. You cannot access them outside the class code. That’s in fact, a definition of encapsulation. Only exposing the required methods, in this case post payment and get schedule.

To take McConnell’s definition I mentioned earlier and apply it to the above example, proper abstraction allows you talk on a higher “abstract” level, about Customer Payment and not worrying about too many details. Encapsulation, like McConnell said, is “the enforcer,” and it is not allowing you to look at the details. How? By only exposing these 2 methods.

Just one more thing: encapsulation = information hiding.

If you just remember one thing about encapsulation, remember that. I hope I helped you.

Related
Encapsulation vs Abstraction – my related blog post

Reference
Design Patterns by Christopher G. Lasater
Code Complete 2 Steve McConnell — one of the best programming books that I recommend/sk