Concept of Component design principles (IV.)

http://blog.csdn.net/lovelion/article/details/8539543

The Stability abstraction principle sap is the last of six component design principles, which are often combined with the stable dependency principle SDP to create a high-quality component dependency structure. Finally, it's the last one.

Stability Abstraction principle (the stable-abstractions Principle, SAP)

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

SAP ties the stability and abstraction of the components together. The SAP principle stipulates that a stable component should be abstract , so that it will have good scalability as well as stability. In addition, it also stipulates that an unstable component should be specific , its instability requires that its internal code should be easy to modify, this modification will not have too much impact on other components.

In a relatively stable component, you should include some abstract classes so that you can extend it.

Together, SAP and SDP form the dip (dependency reversal principle) of the component. The SDP requires that the dependency should be in a stable direction, while SAP specifies that stability implies abstraction and that the stability of the component is consistent with its degree of abstraction. Therefore, reliance should also be directed towards abstraction. According to the dip, in order to reduce the coupling between classes and classes, we want to program for the interface, not for the implementation of programming, in the same way, in order to reduce the coupling between components, we want to program for the abstract component, the dependency should be along the abstract and stable components.

Since there can be more than one class in a component, some of which are abstract, and others are specific, you can measure the abstraction of a component by calculating the " percentage of the total number of classes of abstract classes " when evaluating the degree of abstraction of a component.

Abstract metrics

To measure the abstraction of a component, you need to introduce several metrics:

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

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

A (abstractness): abstract factor.

A = 0 means that there is no abstract class in the component; a = 1 means that all the classes in the component are abstract classes.

We can first calculate the abstract factor a for each component, combined with the two principles of SAP and SDP, it is not difficult to know that the dependence needs to go in a stable direction, but also in the direction of abstraction, you can compare a dependency chain on each component of a value 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, but this is not mandatory.

Main Sequence Analysis

In Uncle Bob's ASD, there is a special section to analyze the relationship between stability and abstraction, and get a main sequence (main Sequence). Sunny think this process is a bit like doing software engineering theory research, and the practice of soft project is still different, but, the development of software engineering need not only the support of theoretical research, but also need the verification of practical experience , and understand how others do research, itself is a very interesting thing, next I introduce how Uncle Bob analyze the relationship between component stability and abstraction.

In order to better study the stability and abstraction of the components, we can introduce a two-dimensional coordinate chart, where the abstract A as the longitudinal axis, the instability I as the horizontal, the vertical axis and the axis of the coordinate scale are from 0 to 1, the most stable, most abstract components in the upper left corner (0,1), that is, when the instability i= 0, when the abstract a=1, the component is the most stable, the most abstract, and the most unstable, the most specific component is located in the lower right corner of the coordinates (1,0), at this time the instability i=1 and abstract a=0. Ideally, we want the components to fall near these two positions, that is, the component is either the most stable, the most abstract, or the most unstable and the most specific, but this is only the ideal situation, most of the components of the abstraction and stability of a certain degree, located between the two points.

Uncle Bob thinks that components near (0,0) are highly stable and specific components, but this component is very rigid because it is specific, cannot be extended, and because it is highly stable, it is difficult to make changes to it. Simply put, the component that is located here is dependent on many other components (stability), but it is difficult to extend and modify (specificity). The area near (0,0) is called the Pain Zone (Zone of Pain).

A component near (a) is also not a good location, where the components have the lowest stability and the highest abstraction, but because of their low stability, no other components depend on them, even if they are highly abstract and cannot be used. So the area near this is called the useless Zone (Zone of uselessness).

We want the designed component to be as far away from the two areas as possible, and connect the track points farthest from both areas into a single line, which is the line connecting (1,0) and (0,1) points, which is called the main sequence (main Sequence), as shown in Figure 1.

Fig. 1 main sequence and excluded area

Components located on the main sequence or near the main sequence have some degree of stability and abstraction, although the ideal position of the component is the two endpoints of the main sequence, but in the actual project, most of the components can be in the main sequence or near the main sequence is very good.

In order to better measure the component design of a system is good enough, finally introduce a measure: the distance to the main sequence .

The distance to the main sequence (short distance) refers to the distance (D) between a component and the main sequence, which is calculated as follows:

The range of values for this measure is [0,0.707].

In addition, you can also use a normalized distance (D ') to indicate that the formula is as follows:

The value range of D ' is [0,1],0 indicates that the component is exactly on the main sequence, and 1 represents the farthest distance from the component to the main sequence.

By using this metric, we can comprehensively analyze the consistency between a component design and the master sequence. You can first calculate the D value for each component, and then review and adjust any components that do not have a D value near 0. This will help the designer to determine which components are easier to maintain, which components are not sensitive to change and are more stable.

In addition, the component design can be statistically analyzed, for example, you can calculate the mean and variance of the D measure of all components in the design, and expect to get a mean and variance are close to 0, that is, as far as possible to conform to the design of the main sequence. With the analysis of variance, we can find some special components, 2, in this map, most of the components are distributed along the main sequence, but there are some components farther from the main sequence, the standard deviation z value of more than 1 or even 2, we need to pay attention to these deviations from the larger components, Try to find out what causes them to be very abstract but with fewer dependents, or very specific but with more dependents, we need to refactor these components if necessary to further improve the design of the system.

Figure 2 Component D-Value distribution map (example)

In addition, we can plot the d ' measure of each component over time to see if the d ' value of a component has changed significantly with the upgrade or evolution of the system version, if a component's d ' in a version If the value changes abnormally or exceeds a predetermined threshold, the reason for the change needs to be identified in order to perform a better refactoring of the system.

Summary

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

reuse-Release equivalence principle (REP ): The granularity of reuse is the granularity of the release.

Common Reuse principle (CRP ): Classes in a component need to be reused together. If you reuse one of the classes in your component, then reuse all of them.

Common closure principle (CCP ): All classes in a component should be closed together for the same type of change. A change that affects one component affects all classes in that component and does not affect other components.

non-cyclic dependency principle (ADP : The ring is not allowed in the component's dependency diagram.

Stable Dependency principle (SDP ): Rely on a stable direction.

Stable abstraction principle (SAP): The degree of abstraction of a component should be consistent with its degree of stability.

At this point, 6 components design principles are all introduced, although some principles of analysis too theory, it seems quite boring, but once in-depth to find it is quite interesting, I hope this article can help you!

"Liu Wei Http://blog.csdn.net/lovelion"

Concept of Component design principles (IV.)