1.SRP----单一责任原则
2.OCP----开闭原则
3.LSP----Liskov替换原则
4.DIP----依赖倒置原则
5.ISP----接口分离原则
敏捷开发提倡简单设计的实践，“并在实现新需求时抓住机会改进设计”以对同类性质的改动封闭，做到由需求的变化驱动设计的进化（我们不能因为设计的退化而责怪需求的变化），同时经验在此起到十分重要的作用，如有经验的设计人员可以凭经验在初始设计时做出必要的抽象来满足ocp原则等，或是在需求变动时确定系统所需的抽象（所需的封闭），当然应及早的刺激这种变化的出现（如测试驱动的开发方法）。
OOD承诺了一系列的好处（灵活性可重用性可维护性），用OO语言设计开发，若要方便的得到这些所谓的好处，有一系列的原则是要遵循的，如SRP，OCP，LSP，ISP等。
SRP（单一职责原则）维护类的简单性，类不应承担一个以上令其变化的原因，否则应考虑分离并重新构造类，但如果的应用的变化方式总是导致类中的职责同时变化，却没必要分离他们
Ocp（开闭原则）使OO系统做到对扩展开放，对修改封闭。OCP的遵循关键在于抽象，其主要实现方式有：定义接口描绘所需的操作，client只需关注接口的调用，子类型可以以任何其选择的方式实现接口，即所谓的stategy模式，或者定义抽象类并于其中实现公共操作，个性操作定义为abstract或virtual，由子类型负责个性化实现，通过此两法，将功能的通用部分和实现细节分离出来。当然，设计人员应该确定（猜测或凭经验）系统对哪种变化做到封闭，因为不可能对所有变化做到封闭，如《敏捷模式实践》中提到shape类型排序处理问题，为做到对排序安排（或变动）的封闭（使得各子类型间无需相互知晓，也可以做到自由安排排序顺序），选择使用“数据驱动”的方式（即单独构造结构表示排序安排—其中以子类类型在结构中的排列位置表先后），于shape基类中实现一次Precedes操作即可，子类型无需分别实现。OCP作为OOD核心所在依赖抽象来实现，但敏捷设计（或者说好的设计）拒绝不成熟的抽象，程序仅应对频繁变化的部分做出抽象。
Liskov替换原则是使得ocp成为可能的原则之一，强调“子类型subtype必须能够替换掉它们的基类型basetype”，控制OO的继承关系安排，在OOD用is-a来确定类间的继承关系，LSP指出这种is-a关系是就行为方式（即类的各操作）而言的，而行为方式是可以合理假设的，是客户程序所依赖的。为遵循LSP，可借用DBC（design by contract）的操作前置条件和后置条件，“要使操作得以执行，前置条件必须为真，执行完毕后，该操作要确保后置条件为真”（为每个方法注明其前置和后置条件十分有帮助），如此，则“在重新声明派生类中操作时，只能使用相等或更弱的前置条件来替换原始的前置条件，只能用相等或更强的后置条件来替换原始的后置条件”（interface和其实现类间 抽象方法和其实现 此二者一定满足前述条件）。同时亦可用前述ocp遵循所用的二模式使设计符合LSP，另外子类型中的异常抛出应考虑在遵循LSP的范围内。
关于提取公共部分的设计工具：“提取公共职责放入超类中，稍后添加的新的子类型可能会以新的方式支持同样的职责，此时原来的超类可能会是一个抽象类”。
DIP（依赖倒置原则），作为framework的设计核心，其相对于传统软件设计而言，通常（传统）软件设计中采用结构化设计用高层模块直接调用底层模块，这样高层模块将严重依赖于底层模块的变动，在OOD中通过为高层模块定义所需使用的服务接口，底层模块现实这样的接口，高层模块通过抽象接口使用下一层（strategy模式所声明的），如此看来接口的拥有者一般是其使用者而非其实现者。通常为了满足DIP-良好OOD的基本底层机制，我么需要找出系统中潜在的抽象，而抽象通常是那些不随具体细节变化而变化的东东。
ISP接口隔离原则，如SRP维护类的简单性一样，ISP用于维护接口的简单和必要性，因为接口是为客户调用的，因此其应该是“大小尺寸合适的”，“胖”接口显然对调用者造成累赘，ISP则用于将“胖”接口分离成多个合适的接口。
当然，在系统设计实现中要做到这些并非容易，单单知道其存在未必做得到将其实现到系统中，开发经验的积累同样重要，但早些知道存在个意识并在做时将其考虑进去，也是积累，慢慢来吧，n多事要做呐。
——敏捷软件开发：原则 模式与实践
==================================另外一个版本
什么是设计原则？
设计原则是基本的工具，应用这些规则可以使你的代码更加灵活、更容易维护，更容易扩展。
基本原则
- 封装变化Encapsulate what varies.
- 面向接口编程而不是实现 Code to an interface rather than to an implementation.
- 优先使用组合而非继承 Favor Composition Over Inheritance
SRP: The single responsibility principle 单一职责
系统中的每一个对象都应该只有一个单独的职责，而所有对象所关注的就是自身职责的完成。
Every object in your system should have a single responsibility ,and all the object s services should be focused on carrying out that single responsibility .
- 每一个职责都是一个设计的变因，需求变化的时候，需求变化反映为类职责的变化。当你系统里面的对象都只有一个变化的原因的时候，你就已经很好的遵循了SRP原则。
- 如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化就可能削弱或者抑制这个类其它职责的能力。这种设计会导致脆弱的设计。当变化发生的时候，设计会遭到意想不到的破坏。
- SRP 让这个系统更容易管理维护，因为不是所有的问题都搅在一起。
- 内聚Cohesion 其实是SRP原则的另外一个名字.你写了高内聚的软件其实就是说你很好的应用了SRP原则。
- 怎么判断一个职责是不是一个对象的呢？你试着让这个对象自己来完成这个职责，比如：“书自己阅读内容”，阅读的职责显然不是书自己的。
- 仅当变化发生时，变化的轴线才具有实际的意义，如果没有征兆，那么应用SRP或者任何其它的原则都是不明智的。
DRY : Don't repeat yourself Principle
通过抽取公共部分放置在一个地方避免代码重复.
Avoid duplicate code by abstracting out things that are common and placing those thing in a single location .
- DRY 很简单，但却是确保我们代码容易维护和复用的关键。
- 你尽力避免重复代码候实际上在做一件什么事情呢？是在确保每一个需求和功能在你的系统中只实现一次，否则就存在浪费！系统用例不存在交集，所以我们的代码更不应该重复，从这个角度看DRY可就不只是在说代码了。
- DRY 关注的是系统内的信息和行为都放在一个单一的，明显的位置。就像你可以猜到正则表达式在.net中的位置一样，因为合理所以可以猜到。
- DRY 原则：如何对系统职能进行良好的分割！职责清晰的界限一定程度上保证了代码的单一性。
OCP : Open-Close Principle开闭原则
类应该对修改关闭，对扩展打开；
Classes should be open for extension ,and closed for modification .
- OCP 关注的是灵活性，改动是通过增加代码进行的，而不是改动现有的代码；
- OCP的应用限定在可能会发生的变化上，通过创建抽象来隔离以后发生的同类变化
- OCP原则传递出来这样一个思想：一旦你写出来了可以工作的代码，就要努力保证这段代码一直可以工作。这可以说是一个底线。稍微提高一点要求,一旦我们的代码质量到了一个水平，我们要尽最大努力保证代码质量不回退。这样的要求使我们面对一个问题的时候不会使用凑活的方法来解决，或者说是放任自流的方式来解决一个问题；比如代码添加了无数对特定数据的处理，特化的代码越来越多，代码意图开始含混不清，开始退化。
- OCP 背后的机制：封装和抽象；封闭是建立在抽象基础上的，使用抽象获得显示的封闭；继承是OCP最简单的例子。除了子类化和方法重载我们还有一些更优雅的方法来实现比如组合；
怎样在不改变源代码（关闭修改）的情况下更改它的行为呢？答案就是抽象，OCP背后的机制就是抽象和多态
- 没有一个可以适应所有情况的贴切的模型！一定会有变化，不可能完全封闭.对程序中的每一个部分都肆意的抽象不是一个好主意，正确的做法是开发人员仅仅对频繁变化的部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。
- OCP是OOD很多说法的核心，如果这个原则有效应用，我们就可以获更强的可维护性 可重用 灵活性 健壮性 LSP是OCP成为可能的主要原则之一
LSP: The Liskov substitution principle
子类必须能够替换基类。
Subtypes must be substitutable for their base types.
- LSP关注的是怎样良好的使用继承.
- 必须要清楚是使用一个Method还是要扩展它，但是绝对不是改变它。
- LSP清晰的指出，OOD的IS-A关系是就行为方式而言，行为方式是可以进行合理假设的，是客户程序所依赖的。
- LSP让我们得出一个重要的结论：一个模型如果孤立的看，并不具有真正意义的有效性。模型的有效性只能通过它的客户程序来表现。必须根据设计的使用者做出的合理假设来审视它。而假设是难以预测的，直到设计臭味出现的时候才处理它们。
- 对于LSP的违反也潜在的违反了OCP
DIP：依赖倒置原则
高层模块不应该依赖于底层模块 二者都应该依赖于抽象
抽象不应该依赖于细节 细节应该依赖于抽象
- 什么是高层模块？高层模块包含了应用程序中重要的策略选择和业务模型。这些高层模块使其所在的应用程序区别于其它。
- 如果高层模块依赖于底层模块，那么在不同的上下文中重用高层模块就会变得十分困难。然而，如果高层模块独立于底层模块，那么高层模块就可以非常容易的被重用。该原则就是框架设计的核心原则。
- 这里的倒置不仅仅是依赖关系的倒置也是接口所有权的倒置。应用了DIP我们会发现往往是客户拥有抽象的接口，而服务者从这些抽象接口派生。
- 这就是著名的Hollywood原则:"Don't call us we'll call you."底层模块实现了在高层模块声明并被高层模块调用的接口。
- 通过倒置我们创建了更灵活 更持久更容易改变的结构
- DIP的简单的启发规则：依赖于抽象；这是一个简单的陈述，该规则建议不应该依赖于具体的类，也就是说程序汇总所有的依赖都应该种植于抽象类或者接口。
- 如果一个类很稳定，那么依赖于它不会造成伤害。然而我们自己的具体类大多是不稳定的，通过把他们隐藏在抽象接口后面可以隔离不稳定性。
- 依赖倒置可以应用于任何存在一个类向另一个类发送消息的地方
- 依赖倒置原则是实现许多面向对象技术多宣称的好处的基本底层机制，是面向对象的标志所在。
ISP:接口隔离原则
不应该强迫客户程序依赖它们不需要的使用的方法。
- 接口不是高内聚的，一个接口可以分成N组方法，那么这个接口就需要使用ISP处理一下。
- 接口的划分是由使用它的客户程序决定的，客户程序是分离的接口也应该是分离的。
- 一个接口中包含太多行为时候，导致它们的客户程序之间产生不正常的依赖关系，我们要做的就是分离接口，实现解耦。
- 应用了ISP之后，客户程序看到的是多个内聚的接口。