Physical hierarchy of C + + large-scale programming

There must be a variety of connections between physical components in the system (Dependon relationships). A good design should be a short interface, easy to understand, easy to use and easy to test. Clearing the physical hierarchy is helpful for well-designed systems.

Easy-to-test design

An important part of quality design is the testability design, if a component is well designed, it is easier to use it to construct the test case, as well as its ease of use for the user, and many times the test case is consistent with the user's scenario. This is consistent with the idea of test-driven in extreme programming. Designed by the use of inverted force.

Rule 1: Distributing the hierarchy of the entire system is more effective than testing only on the upper level.

If the hierarchy definition is clear, it will be convenient to test, and the construction of the test case will be very reasonable. If it is difficult to construct a test case when a hierarchical test is found, or a clear hierarchy is difficult to classify, I am afraid the design of the physical structure has already been problematic.

Rule 2: Quarantine test

It can also be understood as a separate test, for each module's independent testing purpose is to reduce the risk of integration testing. Isolation tests can ensure the effectiveness of individual components. At the same time, it is also a way to check the quality of the design between components. If you want to execute a component separately and rely on many other components, it's a bit difficult to isolate, so you might want to reconsider the design of the component or subsystem.

Rule 3: Non-cyclic physical dependencies

Cyclic dependence, inter-component interdependence.

The benefit of non-cyclic dependencies is that it can be easier to test. There are cyclic dependencies that are even difficult to determine the order of tests. The bigger problem with circular dependencies is that it limits the reuse of components and increases the cost of understanding and use.

To resolve circular dependencies, consider two things: first, repack, and unlock the loop chain. Second, the two or more components of a cyclic dependency are composed of a new component.

Hierarchical and hierarchical numbers

Hierarchy numbers are a way of dividing components into layers. Using the hierarchy number method can be very simple to find out whether the system has

Each of the non-circular graphs can be given a unique level number, and the circular graph cannot. A physical dependency graph that can be assigned a unique level number is called hierarchical.

The diagram contains cases where there are no cyclic dependencies and cyclic dependencies.

There is a circular dependency in the diagram on the right, and the level number of component C is 3 or 4, which cannot be determined.

Hierarchical and clear component relationships provide a clear context for design, testing, and reuse, and a clear map in a large, maze-like system can be a great thing.

Cumulative component Dependencies and component design quality

Cumulative component Dependency (cumulative Component Dependency)

It is a digital expression that represents the overhead required to maintain and test a subsystem.

Definition: On top of all component CI in a subsystem, sum the number of components required for each component CI incremental test.

Examples of CCD calculations:

As can be seen, the same is 3 components, if the loop depends on its ccd=9, but the tree-like words ccd=5, the difference is still very obvious.

With a description mechanism, you can use it to quantify the physical design of the component. It can be optimized with quantification.

But as far as a system is concerned, it may have different ways of optimization, but what is a good standard?

A measure: NCCD (standard additive component dependent)

包含N个组件子系统的CCD值与相同系统树形大小的CCD的值做比较

Taking the design dependency in Figure 3 as an example, apply the formula,

NCCD (vertical dependency) = 6/5 = 1.2

NCCD (cyclic dependency) = 9/5 = 1.4

NCCD (tree dependent) = 5/5 = 1

If the NCCD < 1 can be considered to be relatively horizontal and loosely coupled, it is easy to reuse.

If the NCCD > 1 system has a relatively vertical dependency, or tight coupling.

If the NCCD is far greater than 1, there is a significant cyclic dependency in the system.

NCCD provides a quantitative indicator for the system, and if you want to implement a good system, you still need to think and design constantly.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Physical hierarchy of C + + large-scale programming