关于组件，你真的了解么？

最近经常听到“组件化开发”，那架构设计里，组件到底如何定义、设计和应用呢，今天我们一起来聊聊。

本文主要内容：

• 什么是组件？
• 如何设计组件？
• 如何用组件构建系统？

1、什么是组件？

组件是软件的部署单元，是整个软件系统在部署过程中可以独立完成部署的最小实体/最小单元。

具体的表现大概如下：

• 编译运行语言，组件是一组二进制文件的集合

Java中，组件是jar文件，又称jar包
Ruby中，组件是gem文件
.Net中，组件是DLL文件

• 解释运行语言，组件是一组源代码文件的集合

Python中，组件是一个可以import的Module
PHP中，组件是可以是Redis、Kafka等操作类的封装

什么样的组件是好的组件？

根据组件的定义，组件是整个软件系统在部署过程中可以独立完成部署的最小单元。从部署的角度上来说，多个组件可以链接成独立的可执行文件，也可以最总成部署单元，而单个组件也可以动态加载的插件形式来独立部署。

不论采用哪种形式，好的组件都应该永远保持可以被独立部署的特性，同时意味着组件应该可以被单独开发。

人们为了“偷懒”，为了减少源码合并和编译耗费的时间，而想出的一种东西。可以模块化编译、部署。

2、如何设计组件？

如果说类似SOLID这些编码设计原则，是用于指导我们如何用砖砌墙和盖房间，那么组件构建原则就是用来指导我们如何将这些房间组合成房子的。

用类组合一个组件的专业术语叫做：组件聚合。

2.1 组件聚合遵循的3个基本原则：

• REP：复用/发布等同原则
• CCP：共同闭包原则
• CRP：共同复用原则

即用来决定什么样的类应该被组合成一个组件。

2.1.1 REP：复用/发布等同原则

软件复用的最小粒度应等同于其发布的最小粒度。直白地说，就是要复用一段代码就把它抽成组件。

该原则指导我们组件拆分的粒度。

2.1.2 CCP：共同闭包原则

为了相同目的而同时修改的类，应该放在同一个组件中。该原则指导我们组件拆分的粒度。

一个类不应该同时存在着多个变更原因，将所有可能会被一起修改的类（不论是在源码层面或者是抽象理念层有紧密关系的类）集中在一起，组成组件。由同一个原因引起的代码修改，最好在同一个组件中，如果分散在多个组件中，那么开发、提交、部署的成本都会上升。

CCP针对的就是可维护性。对大部分应用程序，可维护性的重要性要远远高于可复用性。

2.1.3 CRP：共同复用原则

不要强迫一个组件的用户依赖他们不需要的东西。

相信你一定有这种经历，集成了组件A，但组件A依赖了组件B、C。即使组件B、C 你完全用不到，也不得不集成进来。这是因为你只用到了组件A的部分能力，组件A中额外的能力带来了额外的依赖。如果遵循共同复用原则，你需要把A拆分，只保留你要用的部分。

2.2 三原则关系

REP、CCP、CRP 三个原则之间存在彼此竞争的关系，REP 和 CCP 是黏合性原则，它们会让组件变得更大，而 CRP 原则是排除性原则，它会让组件变小。

• 遵守REP、CCP 而忽略 CRP ，就会依赖了太多没有用到的组件和类，而这些组件或类的变动会导致你自己的组件进行太多不必要的发布；
• 遵守 REP 、CRP 而忽略 CCP，因为组件拆分的太细了，一个需求变更可能要改n个组件，带来的成本也是巨大的。

优秀的软件架构师需要而且能够在这三者之间进行平衡。

3、如何用组件构建系统？

3.1 组件依赖/结构图

组件依赖/结构图，不是顶层设计的功能模块图，不与顶层设计的功能模块对应，同时不是用来描述应用程序功能的。

它更像是应用程序在构建性与维护性方面的一张地图，重要目标是指导如何隔离频繁的变更，我们不希望那些频繁变更的组件影响到其他本来应该很稳定的组件。

3.2 组件耦合原则

三个组件耦合原则（基于组件依赖/结构图）：

• 无依赖环原则（ADP）
• 稳定依赖原则（SDP）
• 稳定抽象原则（SAP）

3.2.1 ADP：无依赖环原则

循环依赖中的组件在发布的过程中，都必须要集成另一个它依赖的组件，而环中的组件都互相依赖，不存在独立相对的组件。导致发布困难，如下图情况所示：

消除环依赖的方法，主要是组件依赖关系图中不应该出现环。

1）应用依赖反转原则

2）创建一个新的组件

3.2.2 SDP：稳定依赖原则

依赖必须要指向更稳定的方向。

这里组件的稳定性指的是它的变更成本，和它变更的频繁度没有直接的关联（变更的频繁程度与需求的稳定性更加相关）。影响组件的变更成本的因素有很多，比如组件的代码量大小、复杂度、清晰度等等，最最重要的因素是依赖它的组件数量，让组件难以修改的一个最直接的办法就是让很多其他组件依赖于它！

组件被依赖的越多，则改动影响面越大，改动则越需要慎重，则改动困难程度越高，即改动没有那么随意，则稳定性高。而没有被依赖的组件，则随意改，看心情都行，改动困难程度非常低，则稳定性差。

3.2.3 SAP：稳定抽象原则

一个组件的抽象化程度应该与其稳定性保持一致。

在一个软件系统中，总有些部分是不应该经常发生变更的，通常用于表现该系统的高阶架构设计及一些策略相关的高阶决策。为了防止高阶架构设计和高阶策略难以修改，通常抽象出稳定的接口、抽象类为单独的组件，让具体实现的组件依赖于接口组件，这样它的稳定性就不会影响它的扩展性。

耦合指标

通过 稳定性指标I 和 抽象化程度A 可以推导：D指标（稳定性 I 与其抽象化程度 A 之间的关系）

将不稳定性（I）作为横轴，抽象程度（A）作为纵轴，那么最稳定、只包含抽象类和接口的组件应该位于左上角（0，1），最不稳定、只包含具体实现类，没有任何接口的组件应该位于右下角（1，0），他们连线就是主序列线，位于线上的组件，他们的稳定性和抽象程度相匹配，是设计良好的组件。

左下角位于（0，0）周围区域的组件，它们是非常稳定（注意这里的稳定指的是变更成本）并且非常具体的组件，因为它的抽象程度低，决定了它经常改动的命运，但是又有许多其他组件依赖它，改起来非常痛苦，所以这个区域叫做痛苦区。

右上角区域的组件，没有其他组件依赖它，它自身的抽象程度又很高，很有可能是陈旧的老代码，所以这个区域叫做无用区。

可以用点距离主序列线的距离 Z 来表示组件是否遵循稳定抽象原则，Z 越大表示组件越违背稳定依赖原则。

总结

在了解了什么是组件之后，我们很方便的根据应用程序描绘软件组件依赖/结构图，基于此，介绍了组件聚合需要遵循的基本原则：

• 无依赖环原则（ADP）
• 稳定依赖原则（SDP）
• 稳定抽象原则（SAP）

同时三原则存在互相限制，优秀的软件架构师需要而且能够在这三者之间进行平衡。

对于如何用组件构建系统，组件耦合原则：

• 无依赖环原则（ADP）
• 稳定依赖原则（SDP）
• 稳定抽象原则（SAP）

边界的解耦方式也可以分为3个层次：

• 源码层次：做了接口、类依赖上的解耦，但是放在同一个组件中，通常放在不同的路径下，和不完全边界的省略最后一步一样。
• 部署层次：拆分为可以独立部署的不同组件，比如 iOS 的静态库、动态库，真正运行时处于同一台物理机器上，组件之间通常通过函数调用通讯。
• 服务层次：运行在不同的机器上，通过 url 、网络数据包等方式进行通讯。

从上到下，（开发、部署）成本依次升高，如果低层次的解耦已经满足需要，不要进行高层次的解耦。所以不完全边界能解决的，不要用完全边界，低层次解耦能解决的，不要用高层次解耦。

大家好，我是「架构精进之路」

Thanks for reading!