问题
This question already has an answer here:
- Why use getters and setters/accessors? 38 answers
We always say that data will be encapsulated if we simply define variables private and define getters setters to access those variables. My question is if we can access the variables (data) though via getters and setters, how come data is hidden or safe?
I googled a lot for an explanation, but I found nothing. Every one just said in their blogs and posts that it is a data hiding technique, but it has not been explained/elaborated.
回答1:
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.
回答2:
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.
回答3:
The data is safe, because you can do additional logic in your getter / setter, and it's not possible to change the values of your variable. Imagine your code did not work with a null variable, so in your setter you can check against null values and assign a default value which is != null. So your code is still working, regardless of whether someone tries to set your variable to null.
回答4:
My question is if we can access the variables (data) though via getters and setters, how come data is hidden or safe?
You can encapsulate the logic under getters/setters. For example,
public void setAge(int age) {
if (age < 0) {
this.age = 0;
}
else {
this.age = age;
}
}
回答5:
Continuing Jigar's answer: There are a couple of things that come under encapsulation.
Contract Management: If you make it
public, you are literally making anyone to change it to whatever they want. You can't protect it by adding a constraint. Your setter can make sure data gets modified in an appropriate way.Mutability: You do not always have to have a setter. If there is a property that you wanted to keep immutable for the life span of the object. You just make it private and have no setter for it. It will probably be set via constructor. Then your getter will just return the attribute (if it's immutable) or a copy of the attribute (if attribute is mutable).
回答6:
In general, encapsulation of fields by getters and setters leaves more flexibility for changes.
If fields are accessed directly you are stuck with "stupid fields". Fields can only be written and read. Nothing else can be done while accessing a field.
When using methods you can do whatever you want while setting / reading the value. As markus and Jigar mentioned, validation is possible. In addition, you could decide some day that the value is derived from another value or some actions must be executed if the value changes.
how come data is hidden or safe
Data is neither hidden nor safe by using getters and setters. It just gives you the possibility to make it safe. What is hidden is the implementation and not the data.
回答7:
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.
回答8:
I like the explanation when taking into consideration threads. If you made your fields public, how is your instance going to know when a certain thread changed one of its fields?
The only way to do it would be with encapsulation, or simpler put give getters and setters to that field, thus you always know and can check/react to fields updates, for example.
回答9:
Encapsulation makes code more easy to reuse by other people. Another key reason to use encapsulation is that interfaces can not declare fields, but they can declare methods, which can refer to a field!
Methods are properly named with a verb at the beginning. Such as: getName(), setName(),isDying(). Which can help read code!
来源：https://stackoverflow.com/questions/11966763/java-encapsulation