What is encapsulation?

Being one of the core principles of Object-Oriented Programming, encapsulation is still, from my perspective, not a completely clear one. It would seem that a lot of articles have been written about it, but despite this fact I haven’t found any good (in my opinion) resources, explaining this key Object-Oriented Programming principle.

On a high level, the idea of the principle hides right in its name. “Encapsulation” means packing something in a capsule. Talking about programming, we’d like to have some “black box” that would contain a part of our business logic inside. All we would need is to call methods without thinking about the inner implementation.

The devil hides in details. How can we achieve the encapsulation in our programs? Let’s investigate the problem on the sample of a simple BankAccount class. Imagine that you’re writing a banking application that should display the user their money in different currencies, in our case it will be USD and EUR. How to understand if this class is encapsulated or not?

The answer has two parts. Encapsulation is a combination of two aspects:

1. Privacy
2. Data consistency

Let’s talk about both of them in more detail.

Privacy

Privacy is an ability to hide some implementation details from others’ eyes. In the example above, we hid fields of class and only left DepositUsd and DepositEur methods accessible. So, users of our class can’t write such code:

The compiler will return an error, because the _amountInUsd field is marked as private. Different programming languages implement privacy differently, for instance, C++, C# and Java have access modifiers such as private, protected, public, etc. Golang manages the access to type or package level members using a naming convention. The most important thing is that the access to fields/functions/classes/methods can be restricted, and nobody can change the data, stored in the class object, from the outside of the class.

Most people (actually, not only juniors, but developers with years of experience too) think that the existence of the access management tools is exactly encapsulation. Let’s return to our sample and fill the DepositUsd and DepositEur methods:

All its fields are accessible only inside the class, so nobody can change them. The class provides only two public members — the DepositUsd and DepositEur methods — that contain a logic, protecting our _amountInUsd and _amountInEur fields from negative or zero values.

Is this class encapsulated now or not?

NO. Because the data in this class can be inconsistent.

Data consistency

At first, we have to understand what is the data of class. This is just all class’ fields values. The problem with the code above is that by adding an amount to _amountInUsd, we aren’t changing our _amountInEur field value. I guess, nobody would be happy if they opened their banking application and saw the amount that can’t be converted right between USD and EUR. It is called inconsistent state of the class’ data, when class’ fields are inconsistent.

The fix is quite simple and obvious. When we’re depositing USD on our account, we have to convert the incoming amount to EUR and add it to _amountInEur. Absolutely the same thing we need to do in DepositEur method towards the USD amount. The fixed version would look like this:

Now we always know that the values in our _amountInUsd and _amountInEur are consistent, that means they can always be converted from one to another and back correctly. Users of the BankAccount class can be calm and use the DepositUsd and DepositEur methods without an anxiety and a necessity to dive into the class implementation, which is exactly what has been our goal in the very beginning.

So, only when both of these two conditions are met, we can say that our class is encapsulated. But this principle is applicable not only to class! Encapsulation can be called as a “black box principle” that can (and, actually, should) be used for packages, libraries, modules, microservices, services, and even whole systems, when they integrate with each other. Hope that my article helped you to better understand this (probably the most) important principle in Object-Oriented Programming!