一个软件实体应当对扩展开放，对修改关闭。
原文：Software entities should be open for extension, but closed for modification.
引自：Bertrand Meyer[MEYER88]

这个原则说的是，在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。
换言之，应当可以在不必修改源代码的情况下改变这个模块的行为。

用面向对象的语言来讲，不允许修改的是系统的抽象层，而允许扩展的是系统的实现层。

二、里氏代换原则（LSP）

如果对每一个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P
在所有的对象 o1 都被代换成 o2 时，程序 P 的行为没有变化，那么类型 T2 是类型 T1 的子类型。

换言之，一个软件实体如果使用的是一个基类的话，那么一定适用于其子类，而且它根本不能察觉出
基类对象和子类对象的区别。

里氏代换原则是继承复用的基石。只有当衍生类可以替换掉基类，软件单位的功能不会收到影响时，
基类才能真正被复用，而衍生类也才能够在基类的基础上增加新的行为。

反过来的代换是不成立的。即如果一个软件实体使用的是一个子类的话，那么它不一定使用于基类。
比如，Base 是 Derived 的基类。有一个方法 method1 接受子类对象为参数：
method1(Derived d)
那么一般而已不可以有 method1(b)。 注：b 为 Base 类的实例

三、依赖倒转原则（Dependence Inversion）

依赖倒转原则讲的是：要依赖于抽象，不要依赖于具体。

传统的过程性系统的设计办法倾向于使高层次的模块依赖于低层次的模块；抽象层次依赖于具体层次。
依赖倒转原则是要把这个错的依赖关系倒转过来，这就是“依赖倒转原则”的来由。

通常，依赖（耦合）关系分为三种：

1. 零耦合（Nil Coupling）关系：两个类之间没有耦合关系。

2. 具体耦合（Concrete Coupling）关系：具体性耦合发生在两个具体的（可实例化的）类直接，经由
一个类对另一个具体类的直接引用造成。

3. 抽象耦合（Abstract Coupling）关系：抽象耦合关系发生在一个具体类和一个抽象类（或者java接口）
之间，使两个必须发生关系的类之间存有最大的灵活性。

依赖倒转原则要求客户端依赖于抽象耦合。他的另一种表述是：要针对接口编程、不要针对实现编程。

通常，实现依赖倒转原则的手段是：工厂方法模式、模板方法模式、迭代子模式（这也是 Collection 类型
在可以通过 for 、while 方式遍历的情况下，还提供 iterator 遍历方法供调用方使用的原因）。

四、接口隔离原则（Interface Segregation）

接口隔离原则讲的是：使用多个专门的接口比使用单一的总接口要好。 换言之，从一个客户类的角度来讲：
一个类对另外一个类的依赖性应当是建立在最小的接口上的。

由于每一个接口都代表一个角色，实现一个接口的对象，在他的整个生命周期中都扮演这个角色。因此将
角色划分清楚是系统设计的一个重要工作。因此，一个符合逻辑的推断，不应当

将几个不同的角色都交给同一个接口，而应当交给不同的接口。

过于臃肿的接口是对接口的污染（Interface Contamination）。

五、合成/聚合复用原则（Composite/Aggregate Reuse）

合成/聚合复用原则（CARP）经常又叫合成复用原则（CRP）。合成/聚合复用就是在一个新的对象里面使用一些
已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。这个设计
原则有另一个更简短的表述：要尽量使用合成/聚合，尽量不要使用继承。

Java API 中，有几个明显违反这一原则的例子，其中最为著名的就是 Stack 和 Properties。前者被不当地设置
为 Vector 的子类，而 Properties 被不恰当地设置成 Hashtable 的子类。

一个 Stack 不是一个 Vector（NOT IS-A），所以 Stack 不应当设置成为 Vector 的子类。同样地，一个 Properties
也不是一个 Hashtable。 在这两种情况下，使用聚合比使用继承关系更合适。

由于 Properties 继承了 Hashtable 的行为，因而当 p 是一个 Properties 类型的对象是，p.getProperties(key)
与 p.get(key) 就会给出不同的结果。前者来自于 Properties 本身，因此会利用默认值；而后者则来自于 Hashtable，
因此不会使用默认值。

更糟糕的是，由于 Properties 是 Hashtable 的子类，因此，客户端可以通过类型的转换，直接使用超类的行为。
比如，Properties 假定所有的键和值都是 String 类型的，如果不是，就会导致运行崩溃。但是，客户端完全可以
通过 Hashtable 提供的行为加入任意类型的键和值，绕过 Properties 的接口，并导致 Properties 的内部矛盾和
崩溃。

这样说来，Properties 其实仅仅是有一些 Hashtable 的属性的，换言之，这是一个 "Has-A" 的关系，而不是一个
"Is-A" 的关系。

六、迪米特法则（LoD）

迪米特法则（Law of Demeter）又叫做最少知识原则（Least Knowledge Principle），就是说，一个对象应当对其他
对象有尽可能少的了解。

迪米特法则最初是用来作为面向对象的系统设计风格的一种法则，这条法则实际上是很多著名系统，比如火星登录软件
系统、木星的欧罗巴卫星轨道飞船的软件系统的指导设计原则。

关于迪米特法则，比较有代表性的几种描述如下：

1. 只与你直接的朋友们通信（Only talk to your immediate friends）

2. 不要跟“陌生人”说话（Don't talk to strangers）

3. 每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

迪米特法则的主要用意是控制信息的过载。在将迪米特法则运用到系统设计中时，要注意下面的几点：

1. 在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。一个处在弱耦合中的类一旦被修改，
不会对有关系的类造成波及。

2. 在类的结构设计上，每一个类都应当尽量降低成员的访问权限（Accessibility）。换言之，一个类包装好各自的
private 状态（自己的“秘密”）。 这样一来，想要了解其中的一个类的意义时，不需要了解很多别的类的细节。一个
类不应当 public 自己的属性，而应当提供取值和赋值方法让外界间接访问自己的属性。

3. 在类的设计上，只要有可能，一个类应当设计成不变类。

4. 在对其他类的引用上，一个对象对其对象的引用应当降到最低。

1. 可扩展性（Extensibility）

新的功能可以很容易的加入到系统

2. 灵活性（Flexibility）

可以允许代码修改平稳地发生，而不会设计到很多其他的模块

3. 可插入性（Pluggability）

可以很容易地将一个类抽出去，同时将另一个有同样接口的类加入进来

达成理想软件设计目标的关键是设计的抽象化。

抽象化的基石：接口和抽象类

一、接口 （Interface）

接口是实现构件的可插入性（Pluggability）的关键。

1. 接口保证关联的可插入性

通过接口，我们可以实现动态切换一个类到另一个类的关联关系。 比如 类A 关联了类 B，
如果需求更改，类 A 需要关联类 C，我们只有修改类A 的代码。 如果类B和类C行为相似，
那我们可以提炼出接口 E。类A 只需要关联到接口E，就可以在不修改代码的情况下，自由
切换类A与类B或者类C的关联关系。

2. 接口保证调用的可插入性

同样，一个对象不可避免地需要调用其他对象的方法。这种调用不一定非得是某一个具体类，
而可以是一个接口。这样一来，任何实现了这个接口的具体类都可以被当前对象调用；而当前
对象到底调用的是哪一个具体类的实例则完全可以动态地决定。

因此，接口提供了关联以及方法调用上的可插入性，软件系统的规模越大，生命周期越长，接口
的重要性就越大。接口使得软件系统在灵活性和可扩展性、可插入性方面得到保证。

接口的分类：

1. 单方法接口。 如 Runnable

2. 标识接口。如 Serializable、java.rmi.Remote

3. 常量接口。 不推荐

二、抽象类 （Abstract Class）

抽象类的重要设计原则：

1. 抽象类是用来继承的；具体类不是用来继承的

2. 抽象类应该拥有尽可能多的共同代码 （代码复用、节约内存资源）

3. 抽象类应该拥有尽可能少的数据 （节省内存资源）    



接口与抽象类的优缺比较：

1. 两者最大的区别，java 抽象类可以提供某些方法的部分实现，而java接口则不可以。

2. 子类只能继承一个抽象类，但可以实现多个接口。

3.  代码重构方面。将一个单独的java具体类重构成一个java接口的实现是很容易的，
     而为一个已有的具体类添加一个java抽象类作为抽象类型取不那么容易，因为这个
     具体类有可能已经有了一个超类。

4.  java接口是定义混合类型（Mixin Type）的理想工具。所谓混合类型，就是在一个类
    的主类型之外的次要类型。一个混合类型表明一个类不仅仅具有某个主类型的行为，
    而且具有其他的次要行为。比如 Hashtable


联合使用java接口和java抽象类：

由于java抽象类具有提供缺省实现的优点，而java接口具有其他所有的优点。因此联合使用
两者就是一个很好的选择。

首先，声明类型的工作仍然是java接口承担的，但是同时给出的还有一个java抽象类，为这个
接口给出一个缺省实现。其他同属于这个抽象类型的具体类可以选择实现这个java接口，也可
以选择继承自这个抽象类。

这其实就是缺省适配模式（Default Adapter）。Java API 中也用了这种缺省适配模式，而且全都
遵循一定的命名规范:Abstract + 接口名。比如接口Collection，抽象类的名字是AbstractCollection。

这种联合使用接口和抽象类的做法，可以充分利用两者的优点，克服两者的缺点。