定依赖原则

• 稳定性应该与变更的频繁度没有直接关系，而是应该与变更所需的工作量有关系
  • 工作量：代码体量的大小、复杂度、清晰度
• 让组件难于修改的一个最直接的办法就是让很多其他组件依赖于它。
  • 带有许多入向依赖关系的组件是非常稳定的，因为它的任何变更都需要应用到所有依赖它的组件上
• 稳定性指标
  • 组件的位置稳定性：计算所有入和出的依赖关系
    • 不稳定性：I = Fan-out / (Fan-in + Fan-out), I = 0意味着最稳定，I= 1意味着最不稳定
    • 稳定依赖原则（SDP）：要求每个组件的I指标都必须大于其所依赖组件的I指标。也就是说，组件结构依赖图中各组件的I指标必须按照其依赖关系方向递减
• 我们设计组件架构图的目的就是要决定应该让哪些组件稳定，让哪些组件不稳定
• 常用的修改依赖方向的方法：
  • DIP依赖反转，利用接口与实现
  • 抽象组件：新建一个中间组件

定抽象原则

一个组建的抽象化成都应该与其稳定性保持一致

• 高阶策略应该放在哪里
  • 通常我们不想让业务决策和架构设计经常发生变更，因此他们应该放到更稳定组件中；然而，如果将高阶策略放入稳定组件中，那么用于描述那些策略的源代码就很难被修改了
  • 如何让一个无限稳定的组件（I=0）接受变更呢——开闭原则（OCP）， 抽象类
• 稳定抽象原则（SAP）：为组件的稳定性与它的抽象化程度建立了一种关联。
  • 一方面，该原则要求稳定的组件同时应该是抽象的，这样它的稳定性就不会影响到扩展性。
  • 另一方面，该原则也要求一个不稳定的组件应该包含具体的实现代码，这样它的不稳定性就可以通过具体的代码被轻易修改
• 因此，如果一个组件想要成为稳定组件，那么它就应该由接口和抽象类组成，以便将来做扩展。
  • 如此，这些既稳定又便于扩展的组件可以被组合成既灵活又不会受到过度限制的架构
• 将SAP与SDP这两个原则结合起来，就等于组件层次上的DIP。
• 衡量抽象化程度

假设A指标是对组件抽象化程度的衡量，它的值是组件中抽象类与接口所占的比例

- Nc：组件种类的数量
- Na：组件中抽象类和接口的数量
A = Na➗Nc
复制代码

• 稳定性和抽象化程度相关
• 痛苦区：组件处于（0，0），非常稳定且非常具体
  • 这样的组件在设计上是不佳的，因为它很难被修改，这意味着该组件不能被扩展
  • 当然有些软件结构确实会处于这个区域：数据库的表结构（schema），工具型类库（I=1）
• 无用区：（1，1）这些组件通常是无限抽象的，但是欸有被其他组件依赖，这样的组件往往无法使用。因此我们将这个区域称为无用区

很明显，最多变得组件应该离上述两个区域越远越好；坐落于主序列线上的组件不会为了追求稳定性而被设计得“太过抽象”，也不会为了避免抽象化而被设计得“太过不稳定”

• 在整条主序列线上，组件所能处于最优得位置是线得两端

软件架构

什么是软件架构