OO原则

前言：设计时需要考虑这些原则，但随意使用这些原则会使你的程序出现不必要的复杂性（Needless Complexity）。

参考及说明

本文的撰写，是基于阅读后的梳理

《Agile Software Development：Principles,Patterns.and.Practices 》

1. 开放-封闭原则（Open-Closed Principle）

简称OCP。

（一）概念：

软件实体（类、模块、函数等等）应该是可以拓展的，但是不可修改。

即对扩展开发，对修改封闭。

（二）开发封闭体现何处？

这点我没找到书上的解释，我的理解是，开发封闭是对信息的控制。

如果可以控制在基类层面中的信息，就不要对派生类开发。

如果可以控制在模块内部的信息，就不要对外部暴露。

（三）何时修改

有意思的是，在软件系统的模块设计中，并不能一下子做到模块在之后需求的变化中始终能够保持对修改的封闭。修改设计可以说是不可避免的，但过分设计显然在时间成本和复杂性上都是不明智的。

我很赞成书上的观点：

p.98

只受一次愚弄。

最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象隔离以后发生的同类变化。

（四）获取封闭性的方法

• 使用抽象获取封闭性

通过一个典型的例子Shape的可以很容易理解

但这个设计有个缺点就是，当频繁地创建Shape派生类时，会体现出弊端。

得进一步借助Acyclic Vistor模式来解决弊端。

• 使用“数据驱动”获取封闭性

比如表格机制，类似配置文件的方式。

（五）后果

如果未考虑充分这个原则，会导致程序僵化性（Rigidity）。

2. 单一职责原则（SRP）

（一）概念：

就一个类而言，应该仅有一个引起它变化的原因。

（二）为什么要遵循单一职责原则？

我觉得书上这段说有道理：

p.88

每一个职责都是变化的一个轴线(an axis of change)。当需求变化时，该变化会反应为类的职责的变化。如果一个类承担了多个职责，那么引起它变化的原因就会有多个。

所以当需求变化频繁，或系统足够复杂时，遵循单一职责，分离职责有助于系统在适应需求时仍保持灵活性。

（三）职责 定义的角度

这时候，我对内聚性（一个模块组成元素之间的功能相关性）和职责之间的关系思考了一番。我觉得这句话很关键：

p.89

SRP中，我们把职责定义为“变化的原因”。

这显然是从因果的角度去定义的。

SRP是最基本的原则之一，也是最难运用的之一。从面向对象分析的角度，我们自然地会将职责结合在一起。但我们需要从需求变化的角度去重新审视可能的变化。

（四）如何判断两个职责是否应该被分开？

依赖于应用程序变化的方式。

如果应用程序导致两个职责同时变化，那么就不必分离它们。

变化的轴线仅当实际发生变化时才具有真正的意义。如果没有变化的征兆，应用SRP是不明智的。

我觉得这个变化的征兆，正是系统拓展的潜在可能。甚至在需求分析阶段，就得意识到这种可能的变化。

3. Liskov原则（LSP）

（一）概念：

子类型（subtype）必须能够替换掉它们的基类型。

这点我就直接贴出来效果更好：

可见，子类型并不是从现实生活中去揣摩，之前java入门对子类的理解太过于形象，有失严谨，现在上升到设计层面了，得立即纠正观念。

我觉得LSP的出现，是对设计的继承体系模型的一种考验。

（二）判断继承体系是否遵循LSP

这几乎是个难点，书上举的例子在违背LSP时，都很隐晦，比如正方形与长方形等。建议看书第10章。

有时我们虽然设计出了一个自认为“合理”的模型（继承体系），然而正如书上所说：

p.107

一个模型如果孤立的看，并不具备真正意义上的有效性。模型的有效性只能通过客户程序来体现。

客户程序在拿到类时，在调用时，会有一些前置条件和后置条件的条件，这些条件构成了“契约”。

而我们使用的C++、Java等语言并没有提供这一语言特性。客户程序的“期望”，设计继承体系时，对方法调用的“契约”缺乏足够的思考，正是产生设计违背LSP的一大原因。

（三）面向契约设计

派生类的前置条件和后置条件是：

p.108

Meyer规则： 在重新声明派生类中的例程时，只能使用相等或者更弱的前置条件来替换原始的前置条件，只能使用相等或者更强的后置条件来替换原始的的后置条件。

一个方法，可以注明一个方法的前置条件和后置条件。可以在单元测试中指定契约。

（四）解决方案：

一种方法是，当继承体系违背LSP时，提取公共部分，抽象成接口，来代替继承。

这种情况还是很常见的，特别是当父类的方法，子类无法实现其功能，子类无法替换基类，而两者确实有相同的部分，就抽取重构出来咯。

4. 依赖倒置原则（DIP）

（一）概念：

a. 底层模块不应该依赖于底层模块。两者都应该依赖于抽象。

b. 抽象不应该依赖于细节。细节应该依赖于抽象。

依赖倒置原则是框架设计的核心原则之一。

DIP甚至是面向对象设计与面向过程设计的区别标准之一。

p.86

当高层模块制定了应用策略，并且直接依赖底层配置细节时，就暴露出不灵活性；这种不灵活性是由于++依赖关系的方向++导致的。

解决方法：
使用Strategy模式，实现依赖倒置。

（二）如何倒置依赖

我之前单独看DIP这个名词，实在想不出依赖的倒置，依赖还能倒置？！

其实，“倒置依赖”应当与“依赖于抽象”、“层次化”结合起来理解。

这两张图前后一对比，就清晰了：

• 第一幅图

高层是策略模块，底层是细节实现模块。这幅图，上一层依赖于下一层，这样的坏处就是策略模块要随着细节变化，也丧失了高层设置策略模块的可复用性。这正是面向过程设计的依赖特点。

• 第二张图

可以看出，如何实现依赖倒置的。正是依赖于抽象！底层实现细节依赖于高层策略模块定义的接口。

通过将具体细节隐藏在倒置的接口之后，隔离了它们的不稳定性。

同样，接口维系起了系统各层的隔离性。

（三）具体的情景

a. 当我们应用了DIP，我们往往发现是客户拥有抽象接口，而它们的服务者则从这些抽象接口派生。

b. 框架中，有时有必要创建具体类的实例，而创建这些实例的模块将会依赖于它们。有种情况，字符串是具体的稳定的，所以依赖于它不会造成损害。所以，框架中将类的名字作为配置数据传递给程序。

（四）解除依赖关系的两种方式

• 动态多样性

• 静态多样性

静态多样性，就是泛型、模板。能够解决源代码中的依赖关系，但不能解决动态多样性所有的问题。

新类型会迫使泛型重新编译、部署。

何时使用？

除非有严格的速度性能要求，否则应该优先使用动态多样性。

5. 接口隔离原则

（一）概念：

不应该强迫客户依赖于它们不用的方法。

提到接口隔离，就不得不说“胖类”的概念。胖类比如说，就是一个分析阶段的产物，其中定义了很多方法的接口。

如果客户程序直接依赖该接口，就得面临着由于这些未使用方法的改变所带来的改变。所有，ISP就是保证客户程序仅仅依赖于它们实际调用的方法。

（二）解决方案：

1. 使用多重继承来分离接口。

2. 适配器模式。

比如java GUI监听的事件有很多，使用适配器模式，体现了ISP，将客户程序只与特定的客户程序接口绑定起来。

p.132

通过把胖类分解为多个特定于客户程序的接口，可以实现这个目标。每个特定于客户程序的接口仅仅声明它的特定客户或者客户组的那些函数。接着胖类就可以继承所有于客户程序的接口，并实现它们。这就解除了客户程序和它们没有调用的方法之间 的依赖关系，并使客户程序之间不依赖。

通过两张图，我们就能轻松理解上述的ISP想表述的：

第一张

第二张

接口分离之后

---

其他语录：

每个方法调用的开销是1ns数量级。