设计原理与设计模式

一个对象是一组状态和一系列行为的组合体。状态是对象的内在特性，行为是对象的外在特性。

 

一、类设计原理：

1、开闭原则(The Open Closed Principle: OCP)：A module should be open for extension but closed for modification.

一个模块应该对扩展开放但是对修改关闭。

 

2、里氏替换原则（The Liskov Substitution Principle (LSP)）：

Subclasses should be substitutable for their base classes.

子类可以替换任何地方出现的基类。

 

3、依赖倒置原则Dependency Inversion Principle (DIP)：Depend upon Abstractions. Do not depend upon concretions.

要依赖抽象，不要依赖具象。

依赖倒置原则的2个重要方针：
A. High level modules should not depend upon low level modules. Both should depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.
中文意思为：
A. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
B. 抽象不应该依赖于细节，细节应该依赖于抽象

 

4、接口分离原则（The Interface Segregation Principle (ISP)）：Many client specific interfaces are better than one general purpose interface

使用多个专门的接口比使用单一的总接口总要好。
它包含了2层意思：
- 接口的设计原则：接口的设计应该遵循最小接口原则，不要把用户不使用的方法塞进同一个接口里。
  如果一个接口的方法没有被使用到，则说明该接口过胖，应该将其分割成几个功能专一的接口。
- 接口的依赖（继承）原则：如果一个接口a依赖（继承）另一个接口b，则接口a相当于继承了接口b的方法，那么继承了接口b后的接口a也应该遵循上述原则：不应该包含用户不使用的方法。
  反之，则说明接口a被b给污染了，应该重新设计它们的关系。

如果用户被迫依赖他们不使用的接口，当接口发生改变时，他们也不得不跟着改变。换而言之，一个用户依赖了未使用但被其他用户使用的接口，当其他用户修改该接口时，依赖该接口的所有用户都将受到影响。这显然违反了开闭原则，也不是我们所期望的。

 

二、包结构原则

1、重用发布等价原则（The Release Reuse Equivalency Principle (REP)）：The granule of reuse is the granule of release.

重用的粒度等价于发布的粒度。

1）重用的概念：

重用主要是从用户的观点来看的。
对用户来说，使用某个发布单位（组件，类，类群等），如果作者因为某种原因对其作了修改而发布了一个新的版本，用户会期望在升级为新版本之后，不会影响到原系统的正常运作。
也就是说，对于一个可重用（能供其它用户或系统使用）的元素（组件，类，类群等），作者应该承诺新版本能够兼容旧版本。否则，用户将拒绝使用该元素。
2）发布单位

当用户使用的重用组件被作者修改后，用户希望得到通知，然后决定是否升级或升级的时机。为了能使升级后的系统也能正常运作，用户也希望作者有一个规范的发布，包括版本号，类库的说明等等。
一旦用户决定升级新版本，不管这些修改是否影响到用户，用户也不得不包含新版本所包含的所有类库。

REP规定重用粒度不能小于发布粒度，所有重用元素也必须被一起发布。
发布粒度可以为包（组件），或类等实体，但一个应用往往包含了很多类，所以，具有更大的尺度的包（组件）更加适合作为发布粒度。

重用发布等价原则为我们指明了包的设计方针：
一个包中的元素（类）要么都可重用，要么都不可重用。

 

2、共同封闭原则（Common Closure Principle (CCP)）：Classes that change together, belong together.

一起修改的类，应该放在一起（同一个包里）。
如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。
CCP原则就是把因为某个同样的原因而需要修改的所有类组合进一个包里。如果2个类从物理上或者从概念上联系得非常紧密，它们通常一起发生改变，那么它们应该属于同一个包。

 

共同封闭原则（CCP）从软件功能的角度上为我们规范了包设计的一个原则：在设计包时，相互之间紧密关联的类应该放在同一包里。

 

3、全部重用原则（Common Reuse Principle (CRP)）：Classes that aren’t reused together should not be grouped together.

没有被一起重用的类不应该被组合在一起。

CRP原则帮助我们决定哪些类应该被放到同一个包里。

依赖一个包就是依赖这个包所包含的一切。当一个包发生了改变，并发布新的版本，使用这个包的所有用户都必须在新的包环境下验证他们的工作，即使被他们使用的部分没有发生任何改变。
因为如果包中包含有未被使用的类，即使用户不关心该类是否改变，但用户还是不得不升级该包并对原来的功能加以重新测试。

CRP与REP一样，都是从方便用户重用的角度去设计包，重用者是他们的受益者，CCP则让系统的维护者受益。CCP让包尽可能大（CCP原则加入功能相关的类），CRP则让包尽可能小（CRP原则剔除不使用的类）。它们的出发点不一样，但不相互冲突。

CRP保证了包的内部具有很高的聚合性。

 

4、无环依赖原则（Acyclic Dependencies Principle (ADP)）：The dependencies betwen packages must not form cycles.

包之间的依赖不能是一个环状形式。
1）包的依赖

如果一个包A 中的类引用了包B中的类，我们称包A依赖包B。
“依赖”在具体的程序语言中表现为，如果A依赖B，C/C++语言则在A包的文件/类中通过#include语句包含B包中的文件/类；Java语言则A包的类中通过import语句引入B包中的类。
如果存在2个或2个以上的包A，B，C。A依赖B，B依赖C，C依赖A，形成了一个环状依赖。
包是一个比较合适的发布粒度，当修改了包中的代码（类，模块等）并发布新的版本时，我们需要把该包以及它所依赖的其它包一起发布。发布之后，还需要验证系统是否能在新发布的版本下正常运作。
如果多个包之间形成了循环依赖，比如如图2，A依赖B，B依赖C，C依赖A，我们修改了B并需要发布B的一个新的版本，因为B依赖C，所以发布时应该包含C，但C同时又依赖A，所以又应该把A也包含进发布版本里。
也就是说，依赖结构中，出现在环内的所有包都不得不一起发布。它们形成了一个高耦合体，当项目的规模大到一定程度，包的数目变多时，包与包之间的关系便变得错综复杂，各种测试也将变得非常困难，常常会因为某个不相关的包中的错误而使得测试无法继续。而发布也变得复杂，需要把所有的包一起发布，无疑增加了发布后的验证难度。

 

2）打破循环依赖的方法

A）创建新包

包C要依赖包A，必定A中包含有A，C共通使用的类，把这些共同类抽出来放在一个新的包D里。这样就把C依赖A变成了C依赖D以及A依赖D，从而打破了循环依赖关系。

B）使用DIP（依赖倒置原则）和ISP（接口分隔原则）设计原则。

ISP（接口分隔原则）可以剔除美用到的接口。DIP（依赖倒置原则）在类的调用之间引入抽象层。

 

无环依赖原则（ADP）为我们解决包之间的关系耦合问题。在设计包结构时，不能有循环依赖。

 

5、稳定依赖原则（Stable Dependencies Principle (SDP)）：Depend in the direction of stability.

朝着稳定的方向进行依赖。

包应该依赖比自己更稳定的包。因为如果依赖一个不稳定的包，那么当这个不稳定的包发生变化时，本身稳定的包也不得不发生变化，变得不稳定了。

所谓稳定，在现实生活中是指一个物体具有稳固不变的属性使它很难发生变化。应用到软件概念上，我们认为一个软件是稳定的，是因为这个软件很难发生改变，或更确切地说，是不需要发生改变。一个设计良好，能应对各种变化不需要修改的软件当然是稳定的了，但事实上，往往一个软件常常需要对应某个事先没有预测到的用户需求而不得不发生改变，当这种改变发生时，能把修改控制在最小的范围之内，并能稳定的工作（包括软件本身以及依赖它的其它软件实体等），我们也会认为该软件是相对稳定的。

怎么样让一个软件足够稳定呢？一个确切的方法是，让大量其它软件的包依赖它。一个包被很多其他包依赖是非常稳定的，这是因为被依赖的包为了协调其他包必须做很多的工作来对应各种变化（责任的负担者）。

我们认为包X是稳定的，因为：
- X被很多其他包依赖。相当于责任担当者。
- X没有依赖别的包，它是独立的。
6、稳定抽象等价原则（Stable Abstractions Principle (SAP)）：Stable packages should be abstract packages.

稳定的包应该是抽象的包。
一个包的抽象程度越高，它的稳定性就越高。反之，它的稳定性就越低。一个稳定的包必须是抽象的，反之，不稳定的包必须是具体的。
抽象类或接口通过子类继承扩展行为，这表示抽象类或接口比它们的子类更具有稳定性。总之，为了构成稳定的包，应该提高包内的抽象类或接口的比率；它们的子类可以放在另一个不稳定的包内，该包依赖上述稳定的包，从而遵循了稳定依赖原则（SDP）。