第一条:单一职责原则SRP
中心:就一个类而言,应该仅有一个引起他变化的原因。
把职责分离到单独的类中,因为每一个类都是变化的轴线，当需求变化时,该变化会反映为类的职责的变化，如果一个类承担了多余一个的职责,那么引起他变化的原因就会有多个。
职责定义为“变化的原因”。
如果一个类承担的职责过多,就等于把这些职责耦合在了一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到的破坏。
另一方面，如果应用程序的变化方式总是导致这两个职责同时变化，那么就不必分离它们，实际分离它们就会导致不必要的复杂性的臭味。
SRP是所有原则中最简单的也是最难以正确应用的原则之一。
第二条:开放-封闭原则OCP
中心:软件实体（类，模块，函数等等），应该是可以扩展的，但是不可修改的。
遵循开放-封闭原则设计出的模块具有两个主要特征：1、对于扩展是开放的。2、对于修改是封闭的。
OCP的关键是抽象，对于代码的改动是通过增加新代码进行的，而不是更改现有代码，因此他就不会引起像不遵循OCP原则那样的连锁改动。
通常，我们更愿意一直等到确实需要那些抽象时再把他放进去，“我们愿意被第一颗子弹射中，但是我们不会再被同一支枪射得其他子弹射中”。
可以按照以下的一些方法完成这项工作:
我们首先编写测试.测试描绘了系统的一种使用方法,通过首先编写测试,我们迫使系统成为可测试的,在一个具有可测试的.在一个具有可测试性的系统中发生变化时,我们可以坦然对之,因为我们已经构建了使用系统可测试的抽象,并且通常这些抽象中的许多都会隔离以后发生的其他种类的变化.
在许多方面,OCP都是面向对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处(灵活,可重用,可维护性),然而,并不是说只要使用一种面向对象的语言就是遵循了这个原则,对于程序中的每个部分都肆意进行抽象同样不是一个好主意,正确的做法是,开发人员应该仅仅对程序中呈现出频繁变化的那部分作出抽象.拒绝不成熟的抽象和抽象本身一样重要.
第三条:Liskov替换原则LSP
中心:子类型必须能够替换掉他的基类型。
LSP让我们得到一个非常重要的结论:一个模型，如果孤立的看，并不具有真正意义上的有效性，模型的有效性必须通过他的客户程序来表现。
如果一组类都支持一个公共的职责，那么它们就应该从一个公共的超类继承该职责。如果公共的超类还不存在，那么就创建一个，并把公共的职责放入其中，毕竟这样一个类的有用性是确定无疑的。
有一些简单的启发规则可以提供一些有关违反LSP的提示，这些规则都和以某种方式从其基类中去除某功能的派生类有关，完成的功能少于其基类的派生类通常是不能替换其基类的，因此就违反了LSP。
另外一种违反LSP的规则形式是在派生类的方法中添加了其基类不会抛出的异常，如果基类的使用者不期望这些异常，那么把它们添加到派生类的方法中就会导致不可替代性，此时要遵循LSP，要么就必须改变使用者的期望，要么派生类就不应该抛出这些异常。
OCP是OOD中很多说法的核心。如果这个原则应用的有效，应用程序就会具有更多的可维护性，可重用性以及健壮性，LSP是使用OCP成为可能的主要原则之一。
第四条：依赖倒置原则DIP
中心：1、高层模块不应该依赖低层模块。二者都应该依赖于抽象。
2、抽象不应该依赖于细节。细节应该依赖于抽象
本应该是高层的策略设置模块去影响低层细节实现的模块的，包含高层业务规则的模块应该优先并独立于包含实现细节的模块，无论如何高层模块都不应该依赖于低层模块。
我们更希望能够重用的是高层策略模块，如果高层模块独立于底层模块，那么高层模块就能更容易的被重用，该原则是框架的设计核心原则。
所有结构良好的面向对象的架构都具有清晰的层次定义，每个层次通过一个定义良好的、受控制的接口向外提供一组内聚的服务。
每个较高的层次都为它所需要服务声明一个抽象接口，较低层次实现了这些抽象接口，每个高层类都通过接口使用下一层，这样高层就不依赖于低层。低层反而依赖于在高层中声明的抽象服务接口。
这种倒置不仅仅是依赖关系的倒置。它也是接口所有权的倒置。
依赖倒置可以应用于任何一个类向另一个类发送消息的地方。
违反DIP，高层策略没有和底层实现分离，抽象没有和具体细节分离，没有这种分离，高层策略就自动的依赖于低层模块，抽象就自动的依赖于具体细节。
第五条：接口隔离原则ISP
中心：这个原则用来处理“胖”接口所具有的缺点。如果累的接口不是内聚的，就表示该类具有胖的接口。换句话说，类的胖接口可以分解成多组方法，每一组方法服务于一组不同的客户端程序。
不应该强迫客户依赖于它们不用的方法。
如果一个客户端程序依赖于一个含有它不使用的方法的类，但其他客户端缺要使用该方法，那当其他客户端对这个类改变时，就会影响到这