问题
After going through SO questions, I learnt that,
Encapsulation is about protecting invariants and hiding implementation details.
Abstraction has to do with separating interface from implementation.
From class room java training, I learnt that, Encapsulation has following advantages,
Why encapsulation is your friend?
[1] The implementation is independent of the functionality. A programmer who has the documentation of the interface can implement a new version of the module or ADT independently. A new, better implementation can replace an old one.
[2] Encapsulation prevents Doug from writing applications that corrupt a module’s internal data. In real-world programming, encapsulation reduces debugging time. A lot.
[3] ADTs can guarantee that their invariants are preserved.
[4] Teamwork. Once you’ve rigorously defined interfaces between modules, each programmer can independently implement a module without having access to the other modules. A large, complex programming project can be broken up into dozens of pieces.
[5] Documentation and maintainability. By defining an unambiguous interface, you make it easier for other programmers to fix bugs that arise years after you’ve left the company. Many bugs are a result of unforeseen interactions between modules. If there’s a clear specification of each interface and each module’s behavior, bugs are easier to trace.
[6] When your Project doesn’t work, it will be easier to figure out which teammate to blame.
Question 1:
Wrt Point1(above) says, "A new, better implementation can replace an old one.". This is the goal of abstraction but not encapsulation. Am I correct?
Question 2:
Wrt Point 4(above), How Encapsulation help programmer to independently implement module without having access to other modules? How does parallel implementation of modules has anything to do with Encapsulation? Because Encapsulation is about protecting in-variants. This answer also supports my argument
回答1:
(1) Interface should be interpreted broadly; because it has some specific technical meanings, I tend to prefer the term contract (from "design by contract") to mean the same thing. It's the formal specification of how to interact with a particular module (or kind of module). An excellent example is the Collections API; a List is most often an ArrayList, but it can be a LinkedList, an ImmutableList, or something more exotic like a lazy-load database proxy. I almost never care in my code which specific type it is; I just interact with the List interface.
(2) If actual Java interfaces (or the equivalent) are used, it's very easy to create mock or scaffold versions of a component to be used while it's under development. For example, I just implemented a system that sends e-mail. While I was getting the rest of the system ready to actually issue the orders to send, I used a fake mail service that just wrote log messages pretending to send the mail. That way, I could test that the parts of my system that were supposed to invoke the mail service worked correctly independently of actually sending mail.
On a much larger scale, I use Spring MVC to handle the Web tier of my applications. Spring MVC interacts with the Servlet API to interface with a servlet container, which is essentially the Web server itself. The Spring team doesn't need to know anything else about the server; several different servlet containers (Tomcat, Jetty, Undertow, WebLogic) have been written by different teams, but since everyone is using a common interface, they don't have to do any further coordination of their development efforts.
回答2:
To answer this question, we must clarify what we mean by "abstraction" and "encapsulation".
Wikipedia defines abstraction as follows:
Abstraction in its main sense is a conceptual process by which general rules and concepts are derived from the usage and classification of specific examples, literal ("real" or "concrete") signifiers, first principles, or other methods. "An abstraction" is the product of this process—a concept that acts as a super-categorical noun for all subordinate concepts, and connects any related concepts as a group, field, or category.
and for mathematics:
Abstraction in mathematics is the process of extracting the underlying essence of a mathematical concept, removing any dependence on real world objects with which it might originally have been connected, and generalizing it so that it has wider applications or matching among other abstract descriptions of equivalent phenomena
and computer science:
In computer science, abstraction is a technique for managing complexity of computer systems. It works by establishing a level of complexity on which a person interacts with the system, suppressing the more complex details below the current level.
In summary, abstraction is the process of generalization, and abstractions are the results of this process.
By generalizing something, we make it more widely applicable (reusable). For instance, if I have a method to sort persons, and a method to sort cats, I may generalize a method to sort anything that can be pairwise compared. This method has numerous applications. It is a useful abstraction.
By generalizing something, we treat an entire group of things the same, and no longer care which concrete thing we are thinking about. In the example above, I have abstracted over the kinds of objects to be sorted, and abstracted away their internal representation.
Abstraction is therefore closely related to the concept of information hiding, which Wikipedia defines as follows:
In computer science, information hiding is the principle of segregation of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed. The protection involves providing a stable interface which protects the remainder of the program from the implementation (the details that are most likely to change).
Written another way, information hiding is the ability to prevent certain aspects of a class or software component from being accessible to its clients, using either programming language features (like private variables) or an explicit exporting policy.
That is, information hiding is a way to enforce abstractions. We don't just permit our callers to think in an abstraction, we force them to, by hiding the knowledge of the concrete things they should not think about.
With that, we can finally talk about encapsulation, which Wikipedia defines as follows:
Encapsulation is the packing of data and functions into a single component. The features of encapsulation are supported using classes in most object-oriented programming languages, although other alternatives also exist. It allows selective hiding of properties and methods in an object by building an impenetrable wall to protect the code from accidental corruption.
That is, encapsulation is a kind of information hiding (we hide fields or methods).
With that theory in mind, on to your questions:
Wrt Point1(above) says, "A new, better implementation can replace an old one.". This is the goal of abstraction but not encapsulation. Am I correct?
Since encapsulation can be used to enforce abstractions, it can promote their use, and can therefore contribute to reaping their benefit. In fact, this is the purpose of encapsulation.
However, you are correct that encapsulation without abstraction does not promote implementation exchange. Such encapsulation has failed to achieve its purpose; it has been misused.
That is, the article you quote tacitly assumes that encapsulation has been used correctly.
How Encapsulation help programmer to independently implement module without having access to other modules? How this parallel implementation of modules has anything to do with Encapsulation? Because Encapsulation is about protecting in-variants.
If invariants are protected through encapsulation, calling code may not need not be aware of this invariant. If so, the invariant has been abstracted away, the development of calling code is not affected by this invariant, i.e. the other module may be developed independent of that invariant.
来源：https://stackoverflow.com/questions/31769882/does-encapsulation-help-develop-multiple-modules-parallely