What is Encapsulation exactly?
This question already has an answer here:
Encapsulation is probably the most misunderstood concept of OOP.
Encapsulation is NOT data hiding!
"Encapsulation" comes from "capsule". It means putting things together, closing them in a package, and the "things" we are talking about here are data and functions. Programming without encapsulation means that functions dealing with data are "floating around", somewhere in your code, and though they deal with your data and even take that particular type as input, they are separated from your data.
Let me make an example without focusing on "public" and the like: if you have a class that deals with complex numbers, which have a real and imaginary part, you could simply define it like this:
class complex {
double real;
double imaginary;
};
With the old, pre-encapsulation style that was used for example in C, to get the absolute value of this number you would define a function like this:
double absolute(double real, double imaginary);
And this wouldn't be connected to the class at all! Of course you could also define a function that takes a class complex as input, but it would still be an external function. Thus, to use it you would have to do this:
complex A;
A.real = 1;
A.imaginary = -3;
and to get the absolute value you would have to call
absolute(A.real, A.imaginary);
Instead, you could use encapsulation and put data and functions together:
class complex {
double real;
double imaginary;
double absolute(); // inside the class, encapsulated into it!
};
and then to get the absolute value you would simply have to call the method like
A.absolute();
This doesn't require data hiding at all. The advantage is that the code is more manageable, because you can clearly see all the related "things" (that is, data and functions) grouped together, so at a glance you know what you have (data) and what you can do with it (methods).
Information hiding wouldn't be possible without this, because it means that you limit access to some members (the private ones) from the outside, therefore you must have some methods inside or you wouldn't be able to do anything with your data!
At the same time, information hiding helps putting encapsulation to good use: if people could access data from the outside, there would be a very high danger to have other coders that write their own (not encapsulated) code to deal with your data, which would at the very least lead to code duplication (ie, useless efforts) and to inconsistencies if the implementations are not perfectly compatible. Instead, data hiding means that to access private data everybody MUST use the public methods that are provided, so that they are the same for everybody.
So encapsulation is required for data hiding to make sense, and at the same time it is helped by data hiding. Together they work well, but they are not the same thing!
Back to your question: in light of this, definition 1 is wrong. And 2, as noted by CommuSoft, isn't really a definition, it's a rule of thumb. And I will add that it's a rule of thumb about when to use data hiding, not encapsulation.
On a side note, electrometro suggests this might be a duplicate of this question. I think it is noteworthy to say that most answers there are wrong, including the top answer, which provides an example of encapsulation that actually is the contrary of encapsulation.
If you want external references, here are two articles about this:
Encapsulation is not information hiding
Abstraction, Encapsulation, and Information Hiding (please note that when he starts a paragraph called "ENCAPSULATION" and quotes a lot of definitions, he's just trying to show the confusion surrounding this topic; those definitions are wrong, as he explains later!)
Hiding data is about control. When you hide data, you hide it from other programmers (your future self included), because they might do something incorrect with the data, because they don't know as much about it as you do. So you want to carefully control how they use the data - in this case, by hiding it, by restricting access and visibility.
Encapsulation isn't really the practice of "protecting everything that is prone to change". Articles that claim this are overgeneralizing, because most software development techniques are about "protecting" things we might change later. What you should know is that it's often a good idea to examine things that are prone to change, and decide what kind of constraints you want to put on how other people see and use those things - how you might encapsulate those things.
...Similarly, encapsulation also isn't really the practice of "putting functions together with data", as a few articles linked in another answer claim. The proper term for that might be modularization, or plain old object oriented programming - there are many related concepts. These techniques can bring about encapsulation, but calling them encapsulation is confusing, especially for beginners. Encapsulation really is about "hiding" data. (To take a slightly advanced example, in JavaScript, you can put a value together with a function either as a property of the function object, or through a closure. Neither of these use fields, they don't involve using methods of a class/object/prototype, both put the data and function "together", but only the closure will encapsulate the data, by imposing access constraints.)
Encapsulation is data hiding, indeed. The reason is to group similar functionality that might change in the future in much more manageable manner.
Encapsulation might be achieved by much more than just using visibility modifiers.
链接地址: http://www.djcxy.com/p/4108.html下一篇: 什么是封装？