Concept of Component Design Principles (IV)

The stable abstraction principle sap is the last of the six component design principles. It is usually combined with the stable dependency principle SDP to create a high-quality component dependency structure. Finally, it is the last one ,.

 

The stable abstraction principle (SAP)

A component shoshould be as abstract as it is stable.
The degree of abstraction of components should be consistent with its degree of stability.

SAP associates the stability and abstraction of components. SAP principles,A stable component should be abstractIn this way, stability and good scalability will be achieved. In addition, it also stipulates that,An unstable component should be specificIts instability requires that the specific internal code should be easy to modify, and such modifications will not have a great impact on other components.

A relatively stable component should contain some abstract classes so that it can be expanded.

SAP and SDP constitute the dip of the component (dependency inversion principle ). SDP requires dependency to be in a stable direction, while sap requires stability to mean abstraction, and the stability of components must be consistent with the abstraction level. Therefore, dependencies should also be abstracted. According to dip, in order to reduce the Coupling Degree between classes, we need to program interfaces instead of implementing programming. Similarly, to reduce the Coupling Degree between components, we need to program abstract components, dependencies should be carried out along abstract and stable components.

Because a component can contain multiple classes, some of which are abstract and others are specific, you can evaluate the abstract degree of a component by calculating the"Percentage of abstract classes in totalTo measure the abstraction of a component.

 

Abstract Measurement

To measure the abstraction of components, the following metrics need to be introduced:

NC (the number of classes): The total number of classes in the component.

Na (the number of abstract classes): Number of abstract classes in a component. An abstract class contains at least one abstract method. The abstract class cannot be instantiated.

A (abstractness): Abstract factor.

A = 0 indicates that no abstract class exists in the component. A = 1 indicates that all classes in the component are abstract classes.

We can first calculate the abstract factor A of each component. Combined with the two principles of SAP and SDP, it is not difficult to know That dependencies must be carried out in a stable direction and in an abstract direction, you can compare the value of each component in a dependency chain to determine whether the dependency chain needs to be adjusted. A value can be used as an indicator to improve and adjust the dependency chain, however, this is not mandatory.

 

Primary Sequence Analysis

In Uncle Bob's ASD, he has a special section to analyze the relationship between stability and abstraction.Main sequence). Sunny thinks this process is a bit like a theoretical study of software engineering, which is different from the practice of software engineering. However,The development of software engineering requires both theoretical research and practical experience.It is also interesting to know how people do research. Next I will introduce how Uncle Bob analyzes the relationship between component stability and abstraction.

To better study the stability and abstraction of components, we can introduce a two-dimensional coordinate chart, where Abstract A is used as the vertical axis and unstable I is used as the horizontal axis, the coordinate scales of the vertical and horizontal axes are from 0 to 1. The most stable and abstract components are located at (0, 1) in the upper left corner of the coordinate. That is to say, when the instability I = 0 and abstraction A = 1, components are the most stable and abstract. Those most unstable and specific components are located at () in the lower right corner of the coordinate. At this time, I = 1 is unstable and abstract a = 0. Ideally, we want all components to be located near these two locations. That is to say, components are either the most stable, the most abstract, or the most unstable and specific, however, this is only an ideal situation. The abstraction and Stability of most components are to some extent, located between these two points.

Bob believes that components near (0, 0) are highly stable and specific components, but such components are highly rigid because they are specific, it cannot be expanded, and it is difficult to change it because it is highly stable. Simply put, a component located here is dependent on many other components (stability), but it is difficult to expand and modify (uniqueness ). (0, 0) the area nearby is calledZone of pain).

Components in the vicinity of () are not a good position. Although the components here have the lowest stability and the highest abstraction, they are not dependent on because of their low stability, even with high abstraction, it cannot be used. So the area near () is calledZone of uselessness).

We hope that the components we designed can be as far away from these two regions as possible, and connect the path points that are farthest from these two regions into a line, which is the connection () and) the line of a vertex. This line is calledMain sequence), As shown in figure 1.

 

Figure 1 primary sequence and excluded regions

Components located on the master sequence or near the master sequence have a certain degree of stability and abstraction. Although the ideal position of the component is the two endpoints of the master sequence, in the actual project, most components can be located on the master sequence or near the master sequence.

To better measure whether the component design of a system is good enough, we will introduce a metric:Distance to the main sequence.

The distance to the main sequence (referred to as distance) refers to the distance between a component and the main sequence (d). The formula is as follows:

The value range of this metric value is [0, 0.707].

In addition, you can also use a normalized distance (D') to represent it. The formula is as follows:

The value range of d' is [0, 1]. 0 indicates that the component is located on the master sequence, and 1 indicates that the distance from the component to the master sequence is the farthest.

By using this metric, we can fully analyze the consistency between a component design scheme and the main sequence. You can calculate the dvalue of each component, and then review and adjust all components whose dvalue is not near 0. This will help the designer determine which components are easier to maintain and which components are less sensitive to changes and more stable.

In addition, the component design scheme can be statistically analyzed. For example, the mean and variance of the d metric values of all components in the design can be calculated, in addition, it is expected that the mean and variance are both close to 0, that is, the design of the main sequence is best fit. Through variance analysis, we can find some special components, as shown in Figure 2. In this distribution chart, most components are distributed along the main sequence, but some components are far away from the main sequence, the standard deviation Z value exceeds 1 or 2. we need to pay attention to these components with large deviations and try to find out what causes them to be very abstract but less dependent, or very specific, but there are a large number of dependent people. If necessary, we need to refactor these components to further improve the system design.

Figure 2 component D value distribution chart (example)

In addition, we canDraw the d' metric value distribution chart of each component over timeTo check whether the d' value of a certain (or some) component changes significantly with the upgrade or evolution of the system version, if the d 'value of a component in a certain version changes abnormally or exceeds a preset threshold, you need to find out the reasons for the change so that the system can be better reconstructed.

 

 Summary 

Component Design and dependency between components are good or bad. By applying these six component design principles, you can improve the component design in a certain program.

Reuse-release Equivalence Principle (rep): The granularity of reuse is the granularity of release.

Common Reuse Principle (CRP): Classes in a component must be reused together. If you reuse a class in the component, You need to reuse all the classes.

Common blocking principle (CCP): All classes in a component should be closed for changes of the same type. If a change affects a component, all classes of the component are affected, but other components are not affected.

No-ring dependency principle (ADP): The component dependency graph does not allow loops.

Stable dependency principle (SDP): Dependency in a stable direction.

Stable abstraction principle (SAP): the degree of abstraction of components should be consistent with its degree of stability.

 

At this point, all the six component design principles have been introduced. Although the analysis of some principles is too theoretical and seems boring, it is quite interesting to find them in depth, I hope these articles will help you!

[Author: Liu Wei http://blog.csdn.net/lovelion]