Agile Software Development Principles, Patterns,and Practices 第10-12章读书笔记

第十章 里式替换(LSP)

子类型必须能够替换掉他们的基类型。

 结论：

1. OCP是面向对象设计中很多说法的核心。如果这个原则应用得有效，应用程序就会具有更多的可维护性，可重用性以及健壮性。LSP是使OCP成为可能的主要原则之一。正是子类型的可替换性才使得使用基类类型的模块在无需修改的情况下就可以扩展。这种可替换性必须是开发人员可以隐式依赖的东西。因此，如果没有显式地强制基类类型的契约，那么代码就必须良好地并且明显地表达出这一点。
2. 术语“IS-A”的含义过于宽泛以至于不能作为子类型的定义。子类型的正确定义是“可替换性的”，这里的可替换性可以通过显式或者隐式的契约来定义。

 

 第十一章 依赖倒置(LSP)

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

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

 “倒置”解释：

1. 许多传统的软件开发方法，如结构化分析和设计，总是倾向于创建一些高层模块依赖于低层模块，策略依赖于细节的软件结构。而一个设计良好的面向对象的程序，其依赖程序结构相对于传统的过程式方法设计的通常结构而言就是被“倒置”了。
2. 每个高层类都通过抽象接口使用下一层，这样高层就不依赖于低层。低层反而依赖于在高层中声明的抽象服务接口。

结论：

 

1. 使用传统的过程化程序设计所创建出来的依赖关系结构，策略是依赖于细节的。这是糟糕的，因为这样会使策略受到细节改变的影响。面向对象的程序设计倒置了依赖关系结构，使得细节和策略都依赖于抽象，并且常常是客户拥有服务接口。
2. 依赖倒置关系正好是面向对象设计的标志所在。使用何种语言来编写程序是无关紧要的。如果头程序的依赖关系是倒置的，它就是面向对象的设计。
3. 依赖倒置原则是实现很多面向对象技术所宣称的好处的基本低层机制。

 第十二章 接口隔离原则(ISP)

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

1. 如果强迫客户程序依赖于那些它们不使用的方法，那么这些客户程序就面临着由于这些未使用方法的改变所带来的变更。这无意中导致了所有客户程序之间的耦合。换种说法，如果一个客户程序依赖于一个含有它不使用的方法的类，但是其他客户程序却要使用该方法，那么当其他客户要求这个类改变时，就会影响到这个客户程序。我们希望尽可能地避免这种耦合，因此我们希望分离接口。

结论：

1. “胖类”会导致它们的客户程序之间产生不正常的并且有害的耦合关系。当一个客户程序要求该胖类进行一个改动时，会影响到所有其他的客户程序。因此，客户程序应该仅仅依赖于它们实际调用的方法。通过把胖类的接口分解为多个特定于客户程序的接口，可以实现这个目标。每个特定于客户程序的接口仅仅声明它的特定客户或者客户组调用的那些函数。接着，该胖类就可以继承所有特定于客户程序的接口，并实现他们。这就解除了客户程序和它们没有调用的方法间的依赖关系，并使客户程序之间互不依赖。