关于组件,你真的了解么?

791 阅读8分钟

这是我参与8月更文挑战的第21天,活动详情查看:8月更文挑战

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

本文主要内容:

  • 什么是组件?

  • 如何设计组件?

  • 如何用组件构建系统?

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 、网络数据包等方式进行通讯。

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

·················· END ··················