"Yoga mountain night talk"-chatting "encapsulation and abstraction"

Abstract: encapsulation and abstraction are important concepts in C ++. This article tries to give a brief discussion on this.

Encapsulation is an important feature of OO, which is undoubtedly one of the three features of OO (the other two are inheritance and polymorphism, I also don't want to be entangled in this issue.
What is encapsulation? Encapsulation is an information shielding technology that is used to simplify the problems solved in the real world. For example, when making a call, we only need to simply press a few buttons. We do not need to know the connection between the lines and networks in the phone, so that we can encapsulate the implementation details, this makes complex problems very simple, easy to operate, and greatly reduces the chance of errors.
The main purpose of encapsulation is to separate interfaces from implementations. Through encapsulation, we can hide the internal implementation details, and provide corresponding services to customers through interfaces. Separating interfaces from implementations is the key to avoiding the so-called ripple phenomenon (ripple phenomenon, that is, "one stone sparks a thousand waves ". During software development, a file a is often modified for a specific purpose, and other related files B and C must be modified as a result, to modify files B and C, you need to modify related files D, E, F, and G. This round-robin will cause large-scale modifications and eventually spread to various places of the system in a waterfall. It is like throwing a stone in the center of the lake, causing fluctuations in the whole lake. This is the name of the ripple phenomenon ).
Separating interfaces from implementations is a means of repeated use of software. Its role is mainly reflected in the following four aspects:
1. Reduces the coupling between modules in the system and makes the system more elastic.
2. accurately locating bugs in the software to smaller modules is helpful for software debugging.
3. Reduce system complexity and make it easier for customers to understand and use.
4. The simplicity caused by separation makes it more helpful for repeated use of software.

Abstract is the simplest interface of an object. It provides the customer with the desired service. The key to understanding abstraction lies in Interfaces. abstraction is the abstraction of object interfaces. For a specific object, abstraction is a clear interface, and for a telephone call, a button is its interface (abstraction ).
The key to making good use of abstraction lies in a deep understanding of the issues studied. The well-designed abstraction can separate the description from the Implementation. By providing necessary information, we can hide the implementation details so that customers can use objects in a safer and more predictable way, at the same time, the complexity is reduced, the learning difficulty is reduced through simple interfaces, and the learning efficiency is improved.
A good abstraction should eliminate the idea of "spying" (but some people always try to look at the specific implementation) and follow the abstract programming, this makes the final client code simpler, safer, and more stable. In this regard, the standard library and various quasi-standard libraries are doing the most well.
A good abstraction must provide clear, complete, and easy-to-understand instructions. Dependency on abstract programming is actually dependent on these instructions for programming. It has great advantages over dependency-based programming:
1. reading the instructions is much easier than reading the source code, saving a lot of time and making it easier to understand.
2. We can clearly understand the integrity of a class by explaining its integrity (for example, prefixing conditions, post conditions, and applicability.
3. Through instructions, our interfaces are more flexible and scalable (for example, we can use more effective methods to implement sort interfaces ).
4. required interfaces must be described. Defining interfaces without corresponding descriptions as errors makes it easier to maintain classes.
A good note should be that the interface must provide services and tasks that must be completed, rather than what has already been done.

Encapsulation and abstraction are inseparable.
Encapsulation hides implementation details by providing abstraction, notifying customers of stable services that can be used at will, and details that may change with version updates, for example, there is an interface: void sort (); through the interface description, the customer can know this interface is used for sorting, What is the specific sorting method, the customer does not need to care about, in version 1, Bubble Sorting may be used. In version 2 of upgrade, quick sorting is used. Since the customer does not need to care about details, the method used will not affect the customer's code. We cannot change an published interface/abstract at will. For example, if the sort interface is provided in version 1, this interface must be available in version 2, since the version is released, we cannot know whether this interface is being used. If we disable the sort interface in version 2, the customer code using version 1 cannot be upgraded, if the upgrade is forced, the customer's code may be interrupted, which is particularly evident in COM.