组件，或者叫程序集，是指一种能够被独立部署的二进制单元，一般是以DLL的形式存在的。针对大型的软件系统，良好的组件设计能够把系统分解为一些小的组件，从而使每个开发团队都可以只关注单个的组件而无需关心整个系统。
组件设计需要遵守如下原则：
- 重用-发布等价原则（REP）
即重用粒度就是发布粒度。一个组件中的类要么都是可以重用的，要么就都不可以重用。
- 共同重用原则(CRP)
一个组件中的所有类应该是共同重用的，如果重用了组件中的一个类就应该重用组件中的所有类。即放入一个组件中的类是不可分开的，仅仅依赖其中一部分类的情况是不存在的。
- 共同封闭原则（CCP)
即，一个组件不应该包括多个引起变化的原因。组件中所有类对同一种性质的变化是共同封闭的，一个变化如果对一个封闭的组件产生影响，则将对该组件中的所有类产生影响。但对其他组件将不产生影响。该原则类似开放封闭原则，即对修改应该是封闭的，但对扩展应该是开放的。
- 无环依赖原则
在组件的依赖关系图中不能出现环。通过将系统划分为不同的可发布组件，每个组件作为一个可工作单元有一个或一组开发人员负责。完成之后发布给其他开发人员使用，并通过赋予该组件一个版本号来跟踪该组件。对该组件的更改产生的影响不应该必须扩展到其他组件。
- 稳定抽象原则(SAP)
组件的抽象程度应该与其稳定程度保持一致。即，一个稳定的组件应该也是抽象的，这样他的稳定性就不会无法扩展。另一方面一个不稳定的组件应该是具体的，因为他的不稳定性使其内部代码更易于修改。因此如果一个组件是稳定的，那他就应该包含一些抽象类，这样就可以对他进行扩展。
重用发布等价原则
前言
Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Menter得到。
本文介绍The Release Reuse Equivalency Principle (REP)：重用发布等价原则。
概要
The granule of reuse is the granule of release.
重用粒度等价于发布粒度。
重用的概念
重用主要是从用户的观点来看的。
对用户来说，使用某个发布单位（组件，类，类群等），如果作者因为某种原因对其作了修改而发布了一个新的版本，用户会期望在升级为新版本之后，不会影响到原系统的正常运作。
也就是说，对于一个可重用（能供其它用户或系统使用）的元素（组件，类，类群等），作者应该承诺新版本能够兼容旧版本。否则，用户将拒绝使用该元素。
Robert C. Martin氏给出的对重用的定义：
I prefer to define reuse as follows. I reuse code if, and only if, I never need to look at the source code (other than the public portions of header files). I need only link with static libraries or include dynamic libraries. Whenever these libraries are fixed or enhanced, I receive a new version which I can then integrate into my system when opportunity allows.
代码可以看作为可重用的代码，当且仅当：
- 它的使用者（下称用户）无需看它的源代码
- 用户只需联结静态库或包含动态库
- 当库发生改变（错误纠正，功能增强）时，用户只需要得到一个新的版本便能集成到原有的系统
怎么做到重用呢？
一个组件要做到能够重用，它必须有一个得到良好设计的结构，它所包含所有元素必须也是可以重用的。
因为如果一个为重用而设计的发布单位里，包含了不可重用的元素，当不可重用的元素发生改变时，用户也不得不改变原有系统以适应新的版本。这显然违反了重用的定义规则。
也就是说，一个为重用目的而设计的发布单位里，不能包含不可重用的元素；如果包含了不可重用的元素，它将变得不可重用。
发布单位
当用户使用的重用组件被作者修改后，用户希望得到通知，然后决定是否升级或升级的时机。为了能使升级后的系统也能正常运作，用户也希望作者有一个规范的发布，包括版本号，类库的说明等等。
一旦用户决定升级新版本，不管这些修改是否影响到用户，用户也不得不包含新版本所包含的所有类库。
REP规定重用粒度不能小于发布粒度，所有重用元素也必须被一起发布。
发布粒度可以为包（组件），或类等实体，但一个应用往往包含了很多类，所以，具有更大的尺度的包（组件）更加适合作为发布粒度。
重用发布等价原则为我们指明了包的设计方针：
一个包中的元素（类）要么都可重用，要么都不可重用。
小结
重用发布等价原则（REP）从用户观点的角度上为我们规范了包设计的原则：在设计包时，包中应该包含的元素要么都可以重用，要么都不可以重用。
参考资料
Granularity
by Robert C. Martin。
Principles and Patterns by Robert C. Martin。
无环依赖原则
前言
Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Mentorr得到。
本文介绍The Acyclic Dependencies Principle (ADP)：无环依赖原则，或者非循环依赖原则。
概要
The dependency structure between packages must be a directed acyclic graph (DAG). That is, there must be no cycles in the dependency structure.
包之间的依赖结构必须是一个直接的无环图形（DAG）。也就是说，在依赖结构中不允许出现环（循环依赖）。
换成另一个说法是：
The dependencies between packages must not form cycles.
包之间的依赖不能是一个环状形式。
包的依赖
如果一个包A 中的类引用了包B中的类，我们称包A依赖包B。
“依赖”在具体的程序语言中表现为，如果A依赖B，C/C++语言则在A包的文件/类中通过#include语句包含B包中的文件/类；Java语言则A包的类中通过import语句引入B包中的类。
图1（包A依赖包B）
虚线表示一种依赖关系，箭头表示依赖的方向，箭头所在的一侧就是被依赖的包。
包的循环依赖
我们上面讨论了并用图形表示了包之间的依赖关系。如果存在2个或2个以上的包，它们之间的依赖关系图出现了环状，我们就称包之间存在循环依赖关系。
也就是说它们的依赖结构图根据箭头的方向形成了一个环状的闭合图形。如图：
图2：包的循环依赖
如图：A依赖B，B依赖C，C依赖A，形成了一个环状依赖。
包的非循环依赖原则
包是一个比较合适的发布粒度，当修改了包中的代码（类，模块等）并发布新的版本时，我们需要把该包以及它所依赖的其它包一起发布。发布之后，还需要验证系统是否能在新发布的版本下正常运作。
如果多个包之间形成了循环依赖，比如如图2，A依赖B，B依赖C，C依赖A，我们修改了B并需要发布B的一个新的版本，因为B依赖C，所以发布时应该包含C，但C同时又依赖A，所以又应该把A也包含进发布版本里。
也就是说，依赖结构中，出现在环内的所有包都不得不一起发布。它们形成了一个高耦合体，当项目的规模大到一定程度，包的数目变多时，包与包之间的关系便变得错综复杂，各种测试也将变得非常困难，常常会因为某个不相关的包中的错误而使得测试无法继续。而发布也变得复杂，需要把所有的包一起发布，无疑增加了发布后的验证难度。
循环依赖的打破方法
如果包的依赖形成了环状结构，怎么样打破这种循环依赖呢？
有2种方法可以打破这种循环依赖关系：第一种方法是创建新的包，第二种方法是使用DIP（依赖倒置原则）和ISP（接口分隔原则）设计原则。
方法一：创建新的包
比如对于图2这种依赖结构：
图2：包的循环依赖
包C要依赖包A，必定A中包含有A，C共通使用的类，把这些共同类抽出来放在一个新的包D里。这样就把C依赖A变成了C依赖D以及A依赖D，从而打破了循环依赖关系。如图：
这样，包的依赖关系就从A->B->C->A变成了：
A->B->C->D
A->D
方法二：DIP与ISP设计原则
ISP（接口分隔原则）可以剔除美用到的接口。DIP（依赖倒置原则）在类的调用之间引入抽象层。
如图,，包A依赖包B（因为包A中的类U使用了包B中的类X）；反过来，包B又依赖包A（因为包B中的类Y使用了包A中的类V）
包A，包B之间就形成了一种循环依赖。
我们使用DIP设计原则为V抽象一个接口IVforY，并把该接口放在B包中。
这样就把Y对V的调用转化为：
V继承IVforY
Y调用IVforY
如图：
这样一来，包B中的类就不依赖任何包A中的类了。
小结
无环依赖原则（ADP）为我们解决包之间的关系耦合问题。在设计包结构时，不能有循环依赖。
参考资料
Granularity by Robert C. Martin。
Principles and Patterns by Robert C. Martin。
稳定抽象等价原则
前言
Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Mentor得到。
本文介绍The Stable Abstractions Principle (SAP)：稳定抽象等价原则。
概要
Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to its stability.
最稳定的包应该是最抽象的包。不稳定的包应该是具体的包。包的抽象程度跟它的稳定性成正比。
换成另一个说法是：
Stable packages should be abstract packages.
稳定的包应该是抽象的包。
包的稳定抽象等价原则
我们在The Stable Dependencies Principle (SDP) - OO设计的稳定依赖原则 一文中谈到了包的稳定性：不容易改变的包应该具有更好的稳定性。
一个包的抽象程度越高，它的稳定性就越高。反之，它的稳定性就越低。一个稳定的包必须是抽象的，反之，不稳定的包必须是具体的。
稳定的包的构成
抽象类或接口通过子类继承扩展行为，这表示抽象类或接口比它们的子类更具有稳定性。总之，为了构成稳定的包，应该提高包内的抽象类或接口的比率；它们的子类可以放在另一个不稳定的包内，该包依赖上述稳定的包，从而遵循了稳定依赖原则（SDP）。
理想的体系结构应该是：
不稳定的（容易改变的）包处于上层
- 它们是具体的包实现
稳定的（不容易改变的）包处于下层
- 不容易改变，但容易扩展
- 接口比实现（具体的运行代码）在内在特性上更具有稳定性
图1：遵循稳定依赖原则（SDP）的理想的体系结构
小结
稳定抽象等价原则（SAP）为我们解决包之间的关系耦合问题。在设计包结构时，稳定的包应该是抽象的（由抽象类或接口构成），不稳定的包应该是具体的（由具体的实现类构成）。
参考资料
Principles and Patterns by Robert C. Martin。
稳定依赖原则
The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is.
一个设计中的包之间的依赖应该朝着稳定的方向进行。一个包只应该依赖那些比自己更稳定的包。
前言
Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Mentor得到。
本文介绍The Stable Dependencies Principle (SDP)：稳定依赖原则，或称安定依赖原则。
概要
The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is.
一个设计中的包之间的依赖应该朝着稳定的方向进行。一个包只应该依赖那些比自己更稳定的包。
换成另一个说法是：
Depend in the direction of stability.
朝着稳定的方向进行依赖。
包的依赖
如果一个包A 中的类引用了包B中的类，我们称包A依赖包B。
“依赖”在具体的程序语言中表现为，如果A依赖B，C/C++语言则在A包的文件/类中通过#include语句包含B包中的文件/类；Java语言则A包的类中通过import语句引入B包中的类。
图1（包A依赖包B）
虚线表示一种依赖关系，箭头表示依赖的方向，箭头所在的一侧就是被依赖的包。
包的稳定依赖原则
包应该依赖比自己更稳定的包。因为如果依赖一个不稳定的包，那么当这个不稳定的包发生变化时，本身稳定的包也不得不发生变化，变得不稳定了。
所谓稳定，在现实生活中是指一个物体具有稳固不变的属性使它很难发生变化。应用到软件概念上，我们认为一个软件是稳定的，是因为这个软件很难发生改变，或更确切地说，是不需要发生改变。一个设计良好，能应对各种变化不需要修改的软件当然是稳定的了，但事实上，往往一个软件常常需要对应某个事先没有预测到的用户需求而不得不发生改变，当这种改变发生时，能把修改控制在最小的范围之内，并能稳定的工作（包括软件本身以及依赖它的其它软件实体等），我们也会认为该软件是相对稳定的。
怎么样让一个软件足够稳定呢？一个确切的方法是，让大量其它软件的包依赖它。一个包被很多其他包依赖是非常稳定的，这是因为被依赖的包为了协调其他包必须做很多的工作来对应各种变化（责任的负担者）。
图1：稳定的包X
我们认为X是稳定的，因为：
- X被很多其他包依赖。相当于责任担当着。
- X没有依赖别的包，它是独立的。
相反，下面列出了一个非常不稳定的包Y，如图：
图2：不稳定的包Y
我们认为Y是不稳定的，因为：
- Y没有被其他的包所依赖。不是责任的担当着。
- Y依赖很多别的包。
包的稳定性的判断原则
可以通过下面的方法来判断一个包的稳定系数：
Ca：Afferent Coupling。向心耦合。依赖该包（包含的类）的外部包（类）的数目（i.e. incoming dependencies）。
Ce： Efferent Coupling。离心耦合。被该包依赖的外部包的数目（i.e. outgoing dependencies）。
I： Instability。不稳定性。I=Ce/(Ce+Ca)。它的值处于[0，1]之间。
如图1，X的Ce=0，所以不稳定性I=0，它是稳定的。相反，如图2，Y的Ce=3，Ca=0，所以它的不稳定性I=1，它是不稳定的。
SDP要求一个包的不稳定性I要大于它所依赖的包的不稳定性。“Depend upon packages whose I metric is lower than yours.”
换句话说，沿着依赖的方向，包的不稳定性应该逐渐降低，稳定性应该逐渐升高。
小结
稳定依赖原则（SDP）为我们解决包之间的关系耦合问题。在设计包结构时，包应该只依赖比自己更稳定的包。
参考资料
Granularity by Robert C. Martin。
Principles and Patterns by Robert C. Martin。
共同封闭原则
前言
Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Mentor得到。
本文介绍The Common Closure Principle (CCP)：共同封闭原则。
概要
The classes in a package should be closed together against the same kinds of changes. a change that affects a package affects all the classes in that package.
一个包中所有的类应该对同一种类型的变化关闭。一个变化影响一个包，便影响了包中所有的类。
一个更简短的说法是：
Classes that change together, belong together.
一起修改的类，应该组合在一起（同一个包里）。
如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。
CCP原则就是把因为某个同样的原因而需要修改的所有类组合进一个包里。如果2个类从物理上或者从概念上联系得非常紧密，它们通常一起发生改变，那么它们应该属于同一个包。
CCP跟开闭原则（OCP: Open Closed Principle） 有着很深的渊源关系，CCP的“关闭”（closure）就是OCP所提倡的：classes should be closed for modification but open for extension. 类应该对修改关闭，对扩展开放。但我们知道，100%的“关闭”是不现实的，我们在设计系统时，只能尽量地保持对大多数可预见的修改关闭。
CCP延伸了OCP的“关闭”概念，当因为某个原因需要修改时，把需要修改的范围限制在一个最小范围内的包里。
CCP原则帮助我们决定哪些类应该被放到同一个包里。
小结
共同封闭原则（CCP）从软件功能的角度上为我们规范了包设计的一个原则：在设计包时，相互之间紧密关联的类应该放在同一包里。
参考资料
Granularity by Robert C. Martin。
Principles and Patterns by Robert C. Martin。
全部重用原则
前言
Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Mentor得到。
本文介绍The The Common Reuse Principle (CRP)：全部重用原则。
概要
The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.
包的所有类被一起重用。如果你重用了其中的一个类，就重用全部。
换成另一个比较浅显易懂的说法：
Classes that aren’t reused together should not be grouped together
没有被一起重用的类不应该被组合在一起。
CRP原则帮助我们决定哪些类应该被放到同一个包里。
依赖一个包就是依赖这个包所包含的一切。当一个包发生了改变，并发布新的版本，使用这个包的所有用户都必须在新的包环境下验证他们的工作，即使被他们使用的部分没有发生任何改变。
因为如果包中包含有未被使用的类，即使用户不关心该类是否改变，但用户还是不得不升级该包并对原来的功能加以重新测试。
我们在Interface Segregation Principle (ISP) - OO设计的接口分隔原则 /sysdesign/doc/20071205214949530.html 一文中介绍了一种针对类的设计原则：
Clients should not be forced to depend upon interfaces that they do not use.不能强迫用户去依赖那些他们不使用的接口。
把这个概念应用到更广范围的包上，就是CRP的基本理念：不要把用户不使用的类一起组合进包里。
CRP与REP一样，都是从方便用户重用的角度去设计包，重用者是他们的受益者，CCP则让系统的维护者受益。CCP让包尽可能大（CCP原则加入功能相关的类），CRP则让包尽可能小（CRP原则剔除不使用的类）。它们的出发点不一样，但不相互冲突。
CRP保证了包的内部具有很高的聚合性。
小结
全部重用原则（CRP）从用户的角度上为我们规范了包设计的一个原则：在设计包时，相互之间没有紧密关联的类不应该放在同一包里。
参考资料
Granularity by Robert C. Martin。
Principles and Patterns by Robert C. Martin。
分包原则/包的设计原则/组件（包）设计原则