之前一直断断续续的在看《设计模式之禅》，但是一段时间不接触便渐渐对一些概念性的东西模糊了，再回过头看来则会耗时耗力，毕竟设计模式这种东西犹如滴水穿石需持之以恒，结合实际开发才能慢慢的烂熟于心，所以决定将常用设计模式的精华部分摘记下来。下面以设计模式的六大原则开始，一一记之，后面会根据笔记作一个目录汇总。

设计模式中六大原则

• 开闭原则(OCP)

• 职责单一原则(SRP)

• 里氏替换原则(LSP)

• 依赖倒置原则(DIP)

• 接口隔离原则(ISP)

• 合成复用原则(CRP)

• 迪米特法则(LOD)

Open Close Principle

OCP原则(开闭原则):一个软件实体如类、模块和函数等应该对拓展开发，对修改关闭。

注意

开闭原则对拓展开放，对修改关闭，并不意味这不做任何的修改，低层次模块的变化，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。

在业务规则改变的情况下高层模块必须有部分改变以适应新业务，改变要尽量地少，防止变化风险的扩散。 -秦小波 《设计模式之禅》

Single Responsibility Principle

SRP原则(职责单一原则):应该有且只有一个原因引起类的变更。

注意

单一原则的职责划分需要根据具体场景和项目业务逻辑来进行判断。

Liskov Substitution Principle

OCP原则(里氏替换原则)：所有引用基类的地方必须能透明地使用其子类的对象。

通俗点讲：只要父类能出现的地方子类就可以出现，而且替换为子类也不产生任何异常错误，反之则不然。这主要体现在，我们经常使用抽象类/基类做为方法参数，具体使用哪个子类作为参数传入进去，由调用者决定。

通俗点讲，该原则包含以下几点要素

• 子类必须完全实现父类的方法

• 子类可以有自己独有的属性和方法

• 覆盖或者实现父类方法时，参数可以被放大。即父类的某个方法参数为HashMap时，子类参数可以是HashMap，也可以是Map或者更大

• 覆盖或者实现父类的方法时，返回结果可以被缩小。即父类的某个方法返回类型是Map，子类可以是Map，也可以是HashMap或者更小

Dependence Inversion Principle

DIP原则(依赖倒置原则):抽象不应该依赖具体细节，而应该具体细节依赖于抽象，高层模块不应该依赖底层模块。

• 底层模块：不可分割的原子逻辑就是低层模块

• 高层模块：低层模块的组装合成后就是高层模块

• 抽象:Java中体现为基类、抽象类、接口，而不单指抽象类

• 细节:体现为子类、实现类

通俗点讲，该原则包含以下几点要素

• 模块间的依赖应该通过抽象发生，具体实现类之间不应该建立依赖关系

• 接口或者抽象类不依赖于实现类，否则就失去了抽象的意义

• 实现类依赖于接口或者抽象类

• 修改properties等文本配置文件，不破坏依赖倒置原则

总结起来，一句话：“面向接口编程”。

Interface-Segregation Principle

ISP原则(接口隔离原则)：客户端不依赖它不需要的接口；类间的依赖应该建立在最小的接口。

通俗点讲：使用接口时应该建立单一接口，不要建立臃肿庞大的接口，尽量给调用者提供专门的接口，而非多功能接口。(类似职责单一原则，一个接口负责单个模块或业务)

Composite Reuse Principle

CRP原则(合成复用原则)：尽量使用对象组合，而不是继承来达到复用的目的。合成复用原则又称为组合/聚合复用原则。

Low of Demeter

LOD法则(迪米特法则):又称最小知识原则(Least Knowledge Principle,LKP),一个对象应该对其他对象有最少的了解。

该原则包含以下几点要素

• 只和朋友类交流：只耦合该耦合的类

• 朋友间也是有距离的：减少不该public的方法，向外提供一个简洁的访问

• 自家的方法就自己创建：只要该方法不会增加内部的负担，也不会增加类间耦合

通俗点讲：一个类应该对自己需要耦合或者调用的类知道越少越好，被耦合或者调用的类内部和我没有关系，我不需要的东西你就别public了吧。

七种常用面向对象设计原则，如下表所示：

本文章做笔记之用，本文出处：作者xiong_it ，地址：http://blog.csdn.net/xiong_it