2.3 Implementing three basic principles of OOP in Java > 2.3.1 Encapsulation

2.3.1 Encapsulation

The word ‘encapsulate’ literally means ‘to enclose in’. A Java class encapsulates object’s state and behavior. The state is encapsulated in member variables and behavior is encapsulated in methods. That means we have already seen the encapsulation partially when we learned about classes (section 2.2.1). To understand it fully, let us concentrate on ‘objects’ again.

Usually a programming object is shown as a donut like the one in figure 2.1 with its state defined inside and it behavior in the outside ring. There is a reason behind this particular arrangement. If you wish to know the object’s state, you should not directly see it. for instance, to get the balance of the account object, ideally you should ask the account object for it. But before you can ask account object anything, you need to know what operations the account object is capable of. Therefore, the programming objects need to have two things:

an outside that publicly declares the operations you can ask of it and

a private inside concealing its state information.

This idea represents an important concept called encapsulation. The state (inside) of an object is encapsulated by the object’s outside operations. The state can be accessed via methods. This bundling of the object's state (variables) within the protective custody of its methods is called encapsulation. Encapsulating the state and behavior into a neat bundle provides two primary advantages. 

You can achieve modularity in your application

You can hide (or rather protect) sensitive information

Encapsulation for modularity

The real-world problem is divided in independent objects and each object has a fixed responsibility. For instance, bank account and teller can be two independent objects each with a different set of responsibilities. Due to this independence, objects can be written and maintained independent of each other. If the banking system introduces ATM machine, you can simply introduce a new ATM object. You do not need to change the other objects in banking system. Thus, the software design with clearly defined objects is highly modular as the objects can be modified without much affecting other objects.

Thus encapsulation may help to bring modularity; but it is not the only reason to encapsulate. More often you will find ‘encapsulation’ means information hiding. Note that the term encapsulation is used rather widely. At simplest level, even a Java class declaration is a result of encapsulation.

Encapsulation for information hiding

The state is concealed from the outside to protect the it so that none except the object itself can change the state directly. This concealment is called as information hiding and it guarantees that the state of an object cannot be changed inappropriately. Now what if other objects want to change the state of an object. In that case, the object provides a public interface (i.e. API or set-of-public-methods) that other objects can use to communicate with it. The object can then maintain as well as change its private information and methods so that it can be changed at any time without affecting the other objects that depend on it. For instance, in out banking example, any object can use the a bank account object without knowing details of how it internally maintains balance etc.