Principle of definite dependence

  • Stability should be related not directly to the frequency of change, but to the amount of work required to change
    • Workload: size, complexity, clarity of code volume
  • One of the most straightforward ways to make a component difficult to modify is to have many other components depend on it.
    • A component with many inbound dependencies is very stable because any changes to it need to be applied to all components that depend on it
  • Stability index
    • The component’sPosition stability: Calculates all inbound and outbound dependencies
      • Unstable: I= fan-out/(fan-in + fan-out), I= 0 means most stable, I= 1 means most unstable
      • Stable Dependency Principle (SDP) : The I index of each component must be greater than the I index of the component on which it depends. In other words, the INDEX I of each component in the component structure dependency diagram must decrease according to its dependency relationship direction
  • Our goal in designing a component architecture diagram is to determine which components should be stable and which should be unstable
  • Commonly used methods to change the dependency direction:
    • DIP dependency inversion, using interfaces and implementations
    • Abstract component: Create an intermediate component

Principle of definite abstraction

The abstraction of a component should be consistent with its stability

  • Where do higher-order strategies go
    • In general, we don’t want business decisions and architectural designs to change frequently, so they should be put into more stable components; However, if high-level policies are placed in stable components, the source code used to describe those policies can be difficult to modify
    • How do you get an infinitely stable component (I=0) to accept changes — open closed principle (OCP), abstract class
  • The Stable Abstraction Principle (SAP) : Establishes a relationship between the stability of a component and its degree of abstraction.
    • On the one hand, the principle requires that a stable component should also be abstract, so that its stability does not affect extensibility.
    • On the other hand, this principle also requires that an unstable component should contain concrete implementation code so that its instability can be easily modified with concrete code
  • So, if a component wants to be stable,It should then consist of interfaces and abstract classes for future extension.
    • Thus, these stable and extensible components can be combined into architectures that are flexible but not overly restrictive
  • Combining the two principles of SAP and SDP equals DIP at the component level.
  • Measure abstraction

Suppose the A metric is A measure of the abstraction of A component, and its value is the proportion of abstract classes and interfaces in the component

- Nc: indicates the number of component types. - Na: indicates the number of abstract classes and interfaces in A component. A = Na➗NcCopy the code
  • Stability is related to abstraction
  • Pain zone: the component is at (0,0), very stable and very specific
    • Such a component is poorly designed because it is difficult to modify, which means that the component cannot be extended
    • Of course, some software structures do fall into this zone: database schema, utility class library (I=1)
  • Useless areas :(1,1) these components are usually infinitely abstract, but depending on other components, such components can’t be used. So we call this area the useless area

Obviously, at most, the change component should be as far away from these two areas as possible; Components that sit on a main sequence line are not designed to be “too abstract” for stability, nor are they designed to be “too unstable” to avoid abstraction

  • On the entire main sequence line, the optimal position for a component is at both ends of the line

Software architecture

What is software architecture