本文紧张内容：
什么是组件？如何设计组件？如何用组件构建系统？1、什么是组件？组件是软件的支配单元，是全体软件系统在支配过程中可以独立完成支配的最小实体/最小单元。
详细的表现大概如下：
Java中，组件是jar文件，又称jar包Ruby中，组件是gem文件.Net中，组件是DLL文件阐明运行措辞，组件是一组源代码文件的凑集
Python中，组件是一个可以import的ModulePHP中，组件是可以是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 -
作者：架构精进之路，专注软件架构研究，技能学习与个人发展，关注并私信我回答“01”，送你一份程序员发展进阶大礼包。
Thanks for reading!
