一样平常情形下，我们为软件构建中层构造的紧张目标如下：
使软件可容忍被改动。
使软件更随意马虎被理解。
构建可在多个软件系统中复用的组件。
SRP：单一职责原则
任何一个软件模块都该当只对某一类行为者卖力。
单一职责原则哀求一个类或模块只卖力一项职责或功能。它该当只有一个缘故原由引起变革，这样当需求变革时，只须要修正与该职责干系的代码，而不会对其他职责造成影响。这种分离的设计使得代码更加灵巧、可测试和易于理解
OCP：开闭原则
设计良好的打算机软件该当易于扩展，同时抗拒修正。
OCP是我们进行系统架构设计的主导原则，其紧张目标是让系统易于扩展，同时限定其每次被修正所影响的范围。实现办法是通过将系统划分为一系列组件，并且将这些组件间的依赖关系按层次构造进行组织，使得高阶组件不会因低阶组件被修正而受到影响。
LSP：里氏更换原则
子类工具能够更换到程序中的父类工具涌现的任何地方，并且担保程序原有的逻辑行为不变和精确性不被毁坏。
ISP：接口隔离原则
定义1:客户端被强制不应该依赖它不须要的接口。
定义2:类间的依赖关系该当建立在最小的接口上。
接口隔离原则哀求我们只管即便供应小而美的接口，而不是一个弘大臃肿的接口，以试图知足所有的调用者利用，它是对接口的的一种规范和约束。
DIP：依赖反转原则
依赖反转原则（Dependency inversion principle，DIP）是指一种特定的解耦（传统的依赖关系创建在高层次上，而详细的策略设置则运用在低层次的模块上）形式，使得高层次的模块不依赖于低层次的模块的实现细节，依赖关系被颠倒（反转），从而使得低层次模块依赖于高层次模块的需求抽象。
组件构建原则组件
组件是软件的支配单元，是全体软件系统在支配过程中可以独立完成支配的最小实体。
组件发展史
1. 所有源代码一起编译阶段
最早每段程序指定内存地址，库函数和运用程序放在一起每次重新整体编译。
库函数都因此源文件形式存在，而非二进制文件。
缺陷：整体编译非常慢。
2. 库函数单独编译输出二进制件，然后加载到指定的内存地址位置。再加载编译过的运用程序。
缺陷：难以扩展，内存碎片化
3. 链接加载器——天生可定位的二进制文件
由加载器加载到内存的指定位置，并且保存函数的元数据，将函数的引用与函数的定义链接起来。
缺陷：随着程序的膨胀，加载链接周期长。
4. 链接器
将加载和链接分离，链接器可以输出已经完后外部链接的、可以重定位的二进制文件，这种文件可以由一个支持重定位的加载器迅速加载到内存中。使得程序员可以用缓慢的链接器生产出可以很快进行多次加载的可实行文件。
组件聚合
REP：复用/发布等同原则
软件复用的最小粒度应等同于其发布的最小粒度。
从软件设计和架构设计的角度来看，REP原则便是指组件中的类与模块必须是彼此紧密干系的。也便是说，一个组件不能由一组毫无关联的类和模块组成，它们之间该当有一个共同的主题或者大方向。
CCP：共同闭包原则
我们该当将那些会同时修正，并且为相同目的而修正的类放到同一个组件中，而将不会同时修正，并且不会为了相同目的而修正的那些类放到不同的组件中。
CRP：共同复用原则
不要强制一个组件的用户依赖他们不须要的东西。简而言之，CRP原则实际上是在辅导我们：不是紧密相连的类不应该被放在同一个组件里。
REP、CCP、CRP 三个原则之间存在彼此竞争的关系，REP 和 CCP 是黏合性原则，它们会让组件变得更大，而 CRP 原则是打消性原则，它会让组件变小。遵守REP、CCP 而忽略 CRP ，就会依赖了太多没有用到的组件和类，而这些组件或类的变动会导致你自己的组件进行太多不必要的发布；遵守 REP 、CRP 而忽略 CCP，由于组件拆分的太细了，一个需求变更可能要改n个组件，带来的本钱也是巨大的。
组件聚合原则的张力争
一样平常来说，一个软件项目的重心会从该三角区域的右侧开始，先期紧张捐躯的是复用性。然后，随着项目逐渐成熟，其他项目会逐渐开始对其产生依赖，项目重心就会逐渐向该三角区域的左侧滑动。换句话说，一个项目在组件构造设计上的重心是根据该项目的开拓韶光和成熟度不断变动的，我们对组件构造的安排紧张与项目开拓的进度和它被利用的办法有关，与项目本身功能的关系实在很小。
组件的构成安排应随着项目重心的不同，以及研发性与复用性的不同而不断蜕变。
组件耦合
无依赖环原则
组件依赖关系图中不应该涌现环。
针对多个程序员同时修正了同一个源代码文件带来的综合征，逐渐蜕变出了两种办理方案，第一种是“每周构建”，第二种是“无依赖环原则(ADP)”。
循环依赖在组件依赖图中的影响
Entities、Authorizer及Interactors这三个组件事实上被合并成了一个更大的组件。这些组件的程序员现在会相互形成滋扰，由于他们在开拓中都必须利用完备相同的组件版本。
冲破循环依赖
1.运用依赖反转原则(DIP)：
我们可以创建一个User类须要利用的接口，然后将这个接口放入Entities组件，并在Authorizer组件中继续它。这样就将Entities与Authorizer之间的依赖关系反转了，自然也就冲破了循环依赖关系。
2.创建一个新的组件，并让Entities与Authorize这两个组件都依赖于它。将现有的这两个组件中相互依赖的类全部放入新组件。
自上而下的设计
组件构造图是不可能自上而下被设计出来的。它必须随着软件系统的变革而变革和扩展，而不可能在系统构建的最初就被完美设计出来。
稳定依赖原则
依赖关系必须要指向更稳定的方向。
稳定性
带有许多入向依赖关系的组件是非常稳定的，由于它的任何变更都须要运用到所有依赖它的组件上。
X，稳定的组件
Y，一个非常不稳定的组件
稳定性指标
Fan-in：入向依赖，这个指标指代了组件外部类依赖于组件内部类的数量。
Fan-out：出向依赖，这个指标指代了组件内部类依赖于组件外部类的数量。
I：不稳定性，I=Fan-out/(Fan-in+Fan-out)。该指标的范围是[0,1],I=0意味着组件是最稳定的，I=1意味着组件是最不稳定的。
并不是所有组件都该当是稳定的
一个具有三个组件的系统的空想配置
违反SDP的情形
Stable组件中的U利用了Flexible组件中的C
利用DIP来修复这个问题。详细来说便是创造一个UServer组件，并在个中设置一个US接口类。
抽象组件
创建一个只有接口的组件，险些不包含任何可实行的代码，常日会非常稳定，可以被那些相对不稳定的组件依赖。
稳定抽象原则
一个组件的抽象化程度该当与其稳定性保持同等。
高阶策略该当放在哪里
在一个软件系统中，总有些部分是不应该常常发生变更的。这些部分常日用于表现该系统的高阶架构设计及一些策略干系的高阶决策。然而将高阶策略放入稳定组件中，那么用于描述那些策略的源代码就很难被修正。但是OCP原则表明：可以利用抽象创建一个足够灵巧、能够被扩展，而且不须要修正的类是可能的。
稳定抽象原则简介
稳定抽象原则(SAP)为组件的稳定性与它的抽象化程度建立了一种关联。一方面，该原则哀求稳定的组件同时该当是抽象的，这样它的稳定性就不会影响到扩展性。另一方面，该原则也哀求一个不稳定的组件该当包含详细的实当代码，这样它的不稳定性就可以通过详细的代码被轻易修正。
如果一个组件想要成为稳定组件，那么它就该当由接口和抽象类组成，以便将来做扩展。
将SAP与SDP这两个原则结合起来，就即是组件层次上的DIP。由于SDP哀求的是让依赖关系指向更稳定的方向，而SAP则见告我们稳定性本身就隐含了对抽象化的哀求，即依赖关系该当指向更抽象的方向。
衡量抽象化程度
Nc：组件中类的数量。
Na：组件中抽象类和接口的数量。
A：抽象程度，A=Na÷Nc。
A指标的取值范围是从0到1，值为0代表组件中没有任何抽象类，值为1就意味着组件中只有抽象类。
痛楚区
表示组件中抽象类很少，并且代码的不稳定性很低，代码难于修正。范例案例便是数据库的表构造，在可变性上可谓臭名昭著，但是它同时又非常详细，并被非常多的组件依赖。则便是面向工具运用程序与数据库之间的接口这么难以管理，以及每次更新数据库的过程都非常痛楚的缘故原由。
无用区
表明代码被无限抽象，并且没有被其他组件依赖。
避开这两个区域
以是坐落于主序列线上的组件不会为了稳定性而被设计的“太过抽象”，也不会为了避免抽象化而被设计的“太过不稳定”。以是我们只要追求让这些组件位于主序列线上，或者贴近这条线即可。
推举阅读《架构整洁之道》
个人博客：cyz
