也读《敏捷软件开发》--- OOP原则

面向对象程序设计（OOP，Object Oriented Programming）的原则：

1.SRP（Single Responsibility Principle）单一责任原则

“一个类，只能有一个引起它变化的原因。”

在SRP中，我们把职责定义为“变化的原因”。如果你能够想到多于一个动机去改变一个类，那么这个类就具有多于一个的职责。
如果一个类承担了过多的职责，就等于把这些职责耦合在了一起。一个职责的变化可能会消弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏。
不过，在判定一个类的职责时应该考虑实际的发生情况，如果没有征兆就SRP，或者使用任何其他的原则都是不明智的。

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

“软件实体（类、模块、方法等）应该可以扩展的，但是不可修改。”

遵循OCP原则设计出的模块具有以下特征：
1）对扩展是开放的（Open for extension）
这意味着模块的行为是可以通过扩展的形式添加新功能的。
2）对更改时关闭的（Closed for modification）
同时，在对模型进行扩展的时候，不必改动模块的源码或二进制代码（dll、jar等）。

实现遵循这两个原则模块的方法关键是：抽象。
模块可以操作一个抽象体。由于模块依赖于一个固定的抽象体，所以它对应更改可以是关闭的。同时，通过这个抽象体派生类，可以扩展该模块的行为。

不过，遵循OCP代价也是昂贵的。创建正确的抽象是要花费开发时间和精力的。同时，那些抽象也增加了软件设计的复杂性。开发人员有能力处理的抽象数量也是有限的，显然，我们希望把OCP的应用限定到可能发生的变化上是最好的，这就需要开发人员的观察、分析了。

在许多方面，OCP都是面向对象的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处（也就是，灵活性、可重用性和可维护性）。然而，并不是说只要使用一种面向对象语言就要遵循这一原则。对于应用程序中的每一部分都肆意的抽象同样不是一个好主意。正确的做法是，开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。

3.LSP（Liskov Substitution Principle）里氏替换原则

“子类型必须能够替换掉它的基类型。”

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

4.DIP（Dependency-Inversion Principle）依赖倒置原则

“抽象不应该依赖于细节，细节应该依赖于抽象。”

（1）高层模块不应该依赖于底层模块，二者都应该依赖于抽象；
（2）抽象不依赖于具体细节，细节依赖于抽象；
“倒置”一词是相对于面向过程的程序设计而言的，面向过程的程序设计中通常会创建一下高层模块依赖底层模块、策略依赖于具体实现细节的软件结构。而一个良好的面向对象的程序设计，其设计结构相对于传统的面向过程的而言就是“倒置”了。

每一个较高层次都为它所需要的服务声明一个抽象接口，较低层次实现这些接口，每个高层次都通过这些接口使用下一层，这样高层就不用依赖于低层。低层反而依赖于高层提供的接口。

请注意这里的倒置不仅仅是依赖关系的倒置，它也是接口所有权的倒置。我们通常认为工具库应该拥有它们自己的接口。但是当应用了DIP时，我们发现往往是客户拥有抽象接口，而它们的服务提供者则从这些抽象接口派生。

依赖倒置原则是许多面向对象技术所宣称的好处的基本机制。它的正确使用对应创建可重用的框架是必须的。同时它对于构建在变化面前富有弹性的代码也是非常重要的。由于抽象和细节被彼此分离，所以代码页非常容易维护。

5.ISP（Interface Insolution Principle）接口隔离原则

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

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

6.其他
。。。。。。