Large-scale project development: Isolation ("large-scale C + + program Design" book excerpt)

The sixth chapter of the book is segregated. What needs to be defined in the header file primarily in pose? What should be moved to the compilation unit?
The core is still to differentiate between the interface definition and implementation details first. Changes to the implementation details can lead to another compilation of the customer code, logically representing a strong coupling with the customer code.

Implementation details and isolation

The following implementation details are mainly explored. They introduce implementation details in the interface. It is also necessary to consider the contents of isolation:

1. Inherited
2. Layered
   Simply put, a class member has an instance of a class, such as Foo Mfoo. This class will depend on the definition of Foo. When turning to a hold address, there is no problem when the relationship changes from Hasa to Holda. Which is defined as foo* mfoo; foo& Mfoo; This is also the way the Google C + + Coding style previously proposed to reduce the header file dependency, then removed the suggestion, instead: "Do not use the predecessor declaration, the member variable to the pointer type", because it added a logical complexity, such as additional empty processing.
3. inline functions
4. Private members
5. Protect members
6. The compiler generates a default implementation function, such as a copy.
7. Include directives, which are included with the header file.
8. Default number of parameters
9. Enumeration
   In some large projects. Some header files that have a basic enumeration type. Finally become no one dares to change, but more willing to add a header file. In fact, it might as well be defined in a detailed domain or class.

The following authors recommend a few tricks for each detail. Relative light is relatively simple. Several frequently used techniques are described in the following:

1. Protocol class (interface Class)
2. Opaque Pointer and Pimpl
3. Wrapper (wrapper), which is the introduction of the middle tier.

Process interface

Consider the need for upper-level code for the underlying operation. The author proposes a process interface (the procedural Interface) that can be understood in conjunction with a common API, which is a set of functions. To the top of today's components and exposes a subset of the functionality to the user.

The author summarizes the requirements of the programming interface:

1. The interface must provide the necessary functionality to manipulate the underlying system.

2. Interfaces must not expose the exclusive implementation details.
3. Changes in the underlying organization must be isolated from the client program.
4. The overhead associated with the interface must not be too large.

In the implementation mode, the object-oriented wrapper is the best way to achieve this requirement. The process interface is intended for systems that cannot be implemented simply by using a separate wrapper class.

In fact, a large system can be divided into different areas. are implemented in the form of wrapper, respectively. Can control the interface of WebView. And the Web hierarchy in blink.
The main focus of the book is on the operation of the object being held.

Also mentioned above is the opaque Pointer. The handle (handle) mode is also specifically described to manage dynamically allocated objects.

A process interface is neither object-oriented nor particularly aesthetically pleasing. But it does have a big advantage: The process interface can always be used to isolate the organization of a large system from the client program-even when the interface is not considered in the early stages of design.

Isolated or not isolated

Isolation introduces some overhead. Common reasons for choosing whether to isolate are:

1. Exposure (the range used. or fan-in)
2. Access to data performance
3. Performance of creating objects
4. Development costs (forcibly segregated in the absence of clear justification.) Additional development work will be introduced)
5. Number of components (additional components may be added to add maintenance costs)
6. The complexity of the component (introducing new complexity.) Cause difficult to understand and maintain)

The author provides two sets of empirical values for decision-making (Chinese compiled charts are less rigorous, and the 5th chapter has an icon error.) It was two tables, but a table was synthesized. ）。

The relative overhead of the interview

1. Inline function Pass Value: 1
2. inline function Pass-through pointer: 2
3. Non-inline function, non-virtual function: 10
4. virtual function Mechanism: 20

Create costs relative to individual allocations

1. Own initiative (on the stack): 1.5
2. Dynamic (on heap): 100+

The author concludes with a discussion of isolation decisions, which suggest whether isolation takes place in the scope used, the level of performance requirements, and the size of member functions (whether lightweight). High performance requirements do not isolate. Lightweight implementations do not need to be isolated.

The fact is that isolation itself introduces overhead. Suppose to isolate the introduced overhead, or introduce more unstable complexity. Do not be in a hurry to isolate. For large, widely used objects, it should be isolated as early as possible.

Large-scale project development: Isolation ("large-scale C + + program Design" book excerpt)