Java encapsulation [duplicate]

Answer 1

Encapsulation is more than just defining accessor and mutator methods for a class. It is a broader concept of object-oriented programming that consists in minimizing the interdependence between classes and it is typically implemented through information hiding.

The beauty of encapsulation is the power of changing things without affecting its users.

In an object-oriented programming language like Java, you achieve encapsulation by hiding details using the accessibility modifiers (public, protected, private, plus no modifier which implies package private). With these levels of accessibility, you control the level of encapsulation, the less restrictive the level, the more expensive change is when it happens and the more coupled the class is with other dependent classes (i.e. user classes and subclasses).

Therefore, the goal is not to hide the data itself, but the implementation details on how this data is manipulated.

The idea is to provide a public interface through which you gain access to this data. You can later change the internal representation of the data without compromising the public interface of the class. On the contrary, by exposing the data itself, you compromise encapsulation, and therefore, the capacity of changing the way you manipulate the data without affecting its users. You create a dependency on the data itself, and not with the public interface of the class. You would be creating a perfect cocktail for trouble when "change" finally finds you.

There are several reasons why you might want to encapsulate access to your fields. Joshua Bloch in his book Effective Java, in Item 14: Minimize the accessibility of classes and members, mentions several compelling reasons, which I quote here:

• You can limit the values that can be stored in a field (i.e. gender must be F or M).
• You can take actions when the field is modified (trigger event, validate, etc.).
• You can provide thread safety by synchronizing the method.
• You can switch to a new data representation (i.e. calculated fields, different data type)

However, encapsulation is more than hiding fields. In Java you can hide entire classes, by this, hiding the implementation details of an entire API. Think, for example, in the method Arrays.asList(). It returns a List implementation, but you do not care which implementation, as long as it satisfies the List interface, right?. The implementation can be changed in the future without affecting the users of the method.

The Beauty of Encapsulation

Now, in my opinion, to really understand encapsulation, one must first understand abstraction.

Think, for example, in the level of abstraction in the concept of a car. A car is complex in its internal implementation. They have several subsystems, like a transmission system, a brake system, a fuel system, etc.

However, we have simplified its abstraction, and we interact with all cars in the world through the public interface of their abstraction. We know that all cars have a steering wheel through which we control direction, they have a pedal that when you press it you accelerate the car and control speed, and another one that when you press it you make it stop, and you have a gear stick that let you control if you go forward or backward. These features constitute the public interface of the car abstraction. In the morning you can drive a sedan and then get out of it and drive an SUV in the afternoon as if it was the same thing.

However, few of us know the details of how all these features are implemented under the hood. Think of the time when cars did not have a hydraulics directional system. One day, the car manufactures invented it, and they decide it to put it in cars from there on. Still, this did not change the way in which users were interacting with them. At most, users experienced an improvement in the use of the directional system. A change like this was possible because the internal implementation of a car is encapsulated. Changes can be safely done without affecting its public interface.

Now, think that car manufacturers decided to put the fuel cap below the car, and not in one of its sides. You go and buy one of these new cars, and when you run out of gas you go to the gas station, and you do not find the fuel cap. Suddenly you realize it's below the car, but you cannot reach it with the gas pump hose. Now, we have broken the public interface contract, and therefore, the entire world breaks, it falls apart because things are not working the way it was expected. A change like this would cost millions. We would need to change all gas pumps in the world. When we break encapsulation we have to pay a price.

So, as you can see, the goal of encapsulation is to minimize interdependence and facilitate change. You maximize encapsulation by minimizing the exposure of implementation details. The state of a class should only be accessed through its public interface.

I really recommend you to read a paper by Alan Snyder called Encapsulation and Inheritance in Object-Oriented Programming Languages. This link points to the original paper on ACM, but I am pretty sure you will be able to find a PDF copy through Google.

Answer 2

The way I understand your question is, although we declare variables as private, as those variables can be accessed using getters and setters, they are not private. Therefore, what is the meaning of doing that?

Well, when using getters and setters, you can restrict access to the private variables.

I.e.,

private int x;

public int getInt(String password){
 if(password.equals("RealPassword")){
   return x;
  }
}

And the same for the setters.

Answer 3

Data validation is the main answer to your question regarding how encapsulation provides safety if there are accessors and/or mutators in play. Others have mentioned this using examples of having a fail-safe to set a default value in the mutator. You replied that you prefer throwing exceptions instead, which is great, but identifying that you have bad data when you go to use it does not change the fact that you have bad data. Would it therefore not be best to catch the exception before data is modified, i.e., do it in the mutator? This way the actual data is never modified unless the mutator has verified it as being valid, thus the original data is preserved in the event of bad data.

I'm still just a student myself, but I had the same exact though as you when I first encountered encapsulation, so I spent some time figuring it out.