设计原则

在面向对象得世界里，什么是面向对象，为什么要用对象，如何面向对象这些东西在学习和使用设计模式的时候都有认识。
在经过一个学习，实践再学习的一个往复的认知过程中发现在我们说面向对象，说设计模式的时候设计模式的设计原则这个很总要但有很容易被人忽虑有必要再重新拿出来和大家分享。

OOD的五大原则是指
单一职责原则SRP(Single-Responsibility Principle)、
开发封闭原则OCP(Open Closed Principle) 、
里氏换替换原则LSP(Liskov Substitution Principle)、
依赖倒置原则DIP(Dependency Inversion Principle )、
接口隔离原则ISP(Interface Segregation Principle)

一. SRP
   “就一个类而言，应该仅有一个引起它变化的原因。”
也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责
对于何时遵循SRP有以下的考虑：
1.如果应用程序的变化会影响到类中某一种职责，那么就应该将它与另一种职责分开，这样做可以避免客户应用程序和类中的这两职责耦合在一起。
2.如果应用程序的变化总是会导致两个职责同时变化，那么就不必要分离它们。实际上，分离它们会引起不必要的复杂性。

从上可以得知：变化的轴线仅当变化实际发生时才具有真正的意义。如果没有征兆，那么去应用SRP，或者任何其它原则都是不明智。

实际应用：持久化（Persistence）
实际开发中，考虑到业务规则是会频繁改变的，而持久化的方式却不会如此频繁的变化，并且变化的原因也是完全不同的。如果把业务规则和持久化方式绑定到一起，就会为以后的开发、维护造成麻烦。运用分层（layer）架构模式或者TDD（Test Drive Development）开发方式可以很早分离这两个职责，特殊情况下，还可以使用FACADE或者PROXY模式对设计进行重构，分离这两个职责。

二. OCP
   “软件实体(类、模块、函数等)应该是可以扩展的，但是不可修改。”
遵循开闭原则设计出的模块具有两个主要的特征。它们是：
1. “对于扩展是开放的”（Open for extension）。
   这意味着模块的行为是可以扩展的。当应用的需要改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。换句话说，我们可以改变模块的功能。
2. “对于更改是封闭的”（Closed for modification）。
   对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者Java的.jar文件，都无需改动。

经典应用就是有一个客户端程序通过数据访问接口操作数据，对于这套系统来说，一开始计划使用的是SQL Server或Oracle数据库，但是后来考虑到成本，改用免费的MySQL；那么对于客户端程序来说，后来数据的扩展对它没有任何影响，它在不知不觉间就用上了免费好用的MySQL数据库，这全要感谢OCP原则。

对于OCP关键的是抽象
模块可以操作一个抽象体。由于模块依赖于一个固定的抽象体，所以它对于更改可以是关闭的。同时，通过从这个抽象体派生，也可以扩展此模块的行为。
在许多方面，OCP都是面向对象设计的核心所在。但实际应用中，滥用OCP原则也是错误的。正确的做法是应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要

三. LSP
 “子类型必须能够替换掉它们的基类型。”
此原则是Barbara Liskov首次在1988年写下的。所以就叫做Liskov替换原则。她如此写到：
“这里需要如下替换性质：若对每个类型S的对象o1，都存在一个类型T的对象o2，使得在所有针对T编写的程序P中，用o1替换o2后，程序P行为功能不变，则S是T的子类型。

LSP然我们得出一个非常重要的结论：一个模型，如果孤立的看，并不具有真正意义上的有效性。模型的有效性只能通过它的客户程序来表现。在考虑一个特定设计是否恰当时，不能完全孤立的来看这个解决方案。必须要根据该设计的使用者所做出的合理假设来审视它。

有谁知道设计的使用者会做出什么样的合理假设呢？大多数这样的假设都很难预测。事实上，如果试图去预测所有这些假设，我们所得到的系统很可能会充满不必要的复杂性的臭味。因此，像所有其它原则一样了，通常最好的办法就是只预测那些最明显的对于LSP的违反情况，而推迟所有其它的预测，直到出现相关的脆弱性的臭味时，才去处理它们。

IS-A是关于行为的。
LSP清晰的指出，OOD中IS－A关系是就行为方式而言的，行为方式是可以进行合理假设的，是客户程序所依赖的。

基于契约设计
基于契约设计（DBC：Design By Contract）。使用DBC，类的编写者能够显式的规定针对该类的契约。客户代码的编写者可以通过该契约获悉可以依赖的行为方式。契约是通过为每个方法声明的前置条件（preconditions)和后置条件（postconditions)来指定的。要使一个方法得以执行，前置条件必须要为真。执行完毕后，该方法要保证后置条件为真。

在单元测试中指定契约
也可以通过编写单元测试的方式来指定契约。客户代码编写者会去查看这些单元测试，这样他们就可以知道对于要使用的类，应该做什么合理的假设。

启发式规则和习惯用法

1.派生类中的退化函数
  在基类中实现了f()方法，在派生类中的函数f()就是退化的，派生类中的退化函数并不总表示为违反LSP，但是当存在这种情况时，还是值得注意一下的。
2.从派生类中抛出异常
  在派生类的方法中添加了其基类不会抛出的异常。如果基类的使用者不期望这些异常，那么把它们添加到派生类的方法中就会导致不可替换性。此时要遵循LSP，要么就必须改变使用者的期望，要么派生类就不应该抛出这些异常。

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

四. DIP
 “抽象不应该依赖于细节。细节应该依赖于抽象。”
关于这个原则，还有种说法是.“高层不应该依赖于底层，两者都应该依赖于抽象。”其实怎么说都是对的，关键就是要理解一点，只有抽象的东西才是最稳定的，也就是说，我们依赖的是它的稳定。依赖性倒置的策略就是要依赖接口、或抽象函数、或抽象类，而不是依赖于具体的函数和类依赖性倒置的策略就是要依赖接口、或抽象函数、或抽象类，而不是依赖于具体的函数和类

依赖倒转原则虽然强大，但却不易实现，因为依赖倒转的缘故，对象的创建很可能要使用对象工厂，以避免对具体类的直接引用，此原则的使用还会导致大量的类。维护这样的系统需要较好的面向对象的设计知识。
此外，依赖倒转原则假定所有的具体类都是变化的，这也不总是正确的。有一些具体类可能是相当稳定、不会发生变化的，消费这个具体类实例的客户端完全可以依赖于这个具体类。依赖倒转原则虽然强大，但却不易实现，因为依赖倒转的缘故，对象的创建很可能要使用对象工厂，以避免对具体类的直接引用，此原则的使用还会导致大量的类。维护这样的系统需要较好的面向对象的设计知识。
此外，依赖倒转原则假定所有的具体类都是变化的，这也不总是正确的。有一些具体类可能是相当稳定、不会发生变化的，消费这个具体类实例的客户端完全可以依赖于这个具体类

五. ISP
 “不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”
这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

http://www.cnblogs.com/justinw/archive/2006/11/28/574573.html
http://www.jiehoo.com/oo-design-pattern-and-principles.html

http://blog.csdn.net/nirvana_li/archive/2006/05/22/749737.aspx

http://www.cnblogs.com/cxd4321/archive/2006/09/05/495735.html