OOPs – Encapsulation vs Abstraction

Most of you will agree that encapsulation and abstraction together brings a lot of confusion. Most blogs add only confusion further. Lets solve this puzzle.

I started working on this post after my previous post “Understanding abstraction in java“. My goal was to understand encapsulation in java and how it relates to abstraction. As soon as i began, i started going down in more confusion like never before. After browsing many hours and reading some really well written as well as confusing blog entries, i was able to make out some clear understanding. Follow my footprints..

Table of Contents

Encapsulation in simple words
Encapsulation in Detail
Encapsulation vs Abstraction

Encapsulation in simple words

Wrapping data and methods within classes in combination with implementation hiding (through access control) is often called encapsulation. The result is a data type with characteristics and behaviors. Encapsulation essentially has both i.e. information hiding and implementation hiding.

Encapsulation in Detail

I read it somewhere : “Whatever changes, encapsulate it“. It has been quoted as a famous design principle. For that matter in any class, changes can happen in data in runtime and changes in implementation can happen in future releases. So, encapsulation applies to both i.e. data as well as implementation.

Access control or implementation hiding puts boundaries within a data type or class for two important reasons. The first is to establish what the client programmers can and can’t use. This feeds directly into the second reason, which is to separate the interface from the implementation.

If you are sure that client programmers can’t do anything but send messages to the public interface, then you are free to change anything that’s not public (e.g., package access, protected, or private) without breaking client code. Encapsulation helps you in achieving this surety.

Encapsulation vs Abstraction

If you have gone through my last post, you will see that abstraction is essentially an idea, which helps in setting the guidelines. Encapsulation is the mechanism by which we achieve the desired abstraction.

In short, from OOAD perspective:

• Abstraction is more about ‘What‘ a class can do. [Idea]
• Encapsulation is more about ‘How‘ to achieve that functionality. [Implementation]

I have seen many contradictions to this theory over many blogs. So, if you also don’t agree with this, please bear with me. Also, i will request you to put a comment you idea related to topic. I will happily try to relate or negate.

Going forward, i will take example of our well known class HashMap. This class is responsible for storing key-value pair, searching based on key and do more things. From outside, client code only knows the method names and their behavior. It calls these methods and live happily. This is actually what abstraction guidelines are. Abstraction says that client code should call a method to add key-value pair, a method to retrieve value based on key and so on. How it should be done? is not business of abstraction.

And here comes encapsulation, when you start writing actual code. You write HashMap.Entry class and create variable table of type Entry[]. Then you declare all such things private and give public access to only put() and get() methods etc. This is actually encapsulation. A realization of your desired abstraction.

I hope that you have more clarity about java encapsulation and it’s difference with abstraction.

Happy learning !!