Encapsulation has two faces; data abstraction and information hiding. Data abstraction is a type seen from the outside. Information hiding is a type seen from the inside.
Sometime encapsulation is used to mean information hiding only but I think the definition I gave is better because if you encapsulate something you get both an inside and an outside right.
When you interact with objects in the world, you are often only concerned with a subset of their properties. Without this ability to abstract or filter out the extraneous properties of objects, you would find it hard to process the plethora of information bombarding you and concentrate on the task at hand.As a result of abstraction, when two different people interact with the same object, they often deal
with a different subset of attributes. When I drive my car, for example, I need to know the speed of the car and the direction it is going. Because the car is an automatic, I do not need to know the RPMs of the engine, so I filter this information out. On the other hand, this information would be critical to a racecar driver, who would not filter it out.
When constructing objects in OOP applications, it is important to incorporate this concept of abstraction. If you were building a shipping application, you would construct a product object with attributes such as size and weight. The color of the item would be extraneous information and filtered out. On the other hand, when constructing an order-entry application, the color could be important and would be included as an attribute of the product object.
Another important feature of OOP is encapsulation. Encapsulation is the process in which no direct access is granted to the data; instead, it is hidden. If you want to gain access to the data, you have to interact with the object responsible for the data. In the previous inventory example, if you wanted to view or update information on the products, you would have to work through the product object. To
read the data, you would send the product object a message. The product object would then read the value and send back a message telling you what the value is. The product object defines what operations can be performed on the product data. If you send a message to modify the data and the product object determines it is a valid request, it will perform the operation for you and send a message back with the result.
You experience encapsulation in your daily life all the time. Think about a human resources department. They encapsulate (hide) the information about employees. They determine how this data
can be used and manipulated. Any request for the employee data or request to update the data has to be routed through them. Another example is network security. Any request for the security information or a change to a security policy must be made through a network security administrator. The security data is encapsulated from the users of the network. By encapsulating data you make the data of your system more secure and reliable. You know how the data is being accessed and what operations are being performed on the data. This makes program maintenance much easier and also greatly simplifies the debugging process. You can also modify the methods used to work on the data, and if you do not alter how the method is requested and the type of response sent back, then you do not have to alter the other objects using the method. Think about when
you send a letter in the mail. You make a request to the post office to deliver the letter. How the post office accomplishes this is not exposed to you. If it changes the route it uses to mail the letter, it does not affect how you initiate the sending of the letter. You do not have to know the post office’s internal procedures used to deliver the letter.
————— In Short —————-
Abstraction focuses on the outside view of an object (i.e. the interface)Encapsulation (information hiding) prevents clients from seeing its inside view, where the behavior of the abstraction is implemented.