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.

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.

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.

Ed, I think a lot of people have this notion that encapsulation is this and that and that it is very complicated. It’s not. And I think it’s good to think of it in terms of information hiding, especially if you’re new to OO.

However, as you know, encapsulation is very hard to get right. Just like good OO. It’s the art in programming.

BTW, I see you wrote a paper on the subject. I’m sure going to read it.

As Ed said, some may not fully agree. But that’s lacking in detail. So let me explain why *I* don’t agree. Other disagreers’ mileages may vary.

Encapsulation basically means putting stuff together in one package. (Using the term ‘package’ in the generic sense, not necessarily what any given programming language may mean by it.) It may even mean only allowing *programmatic* access to certain bits, as in the definition supplied by the paper Ed references. This doesn’t necessarily hide info *from people*, or from programs *analyzing* the *source code* of your module (as opposed to *using* it). All the more so if you’re working in a language that has no such concepts as public or private, or of being able to separate private things into a separate non-distributed file so that others don’t even know they exist. Think of it as being analogous to a medicine capsule — which may be perfectly clear. Or some small product coming in a plastic blister-pack, which is usually clear (except the occasional sticker, and there may be a box inside, or things sandwiched between pieces of cardboard).

That said, though, I agree that info hiding is a useful *enforcer* of that particular aspect of encapsulation. It won’t help you put things together, but it will help keep the unwashed from taking it apart.

BTW, I found you via with your comment on the_codist(). It was so lacking in detail that I thought it might be spam, except that the domain sounded relevant. Good name!