前言

相信做过编程开发的都应该听说过设计模式，设计模式是历史上的编程大牛经过不断的探索，总结出来的一整套经验的总和。他们总结出来这23种设计模式，告诉我们编程按照这些编程的设计模式可以让我们代码的可重用性，可读写行，可靠性，易理解等各方面达到一种最优的效果。所以每个做技术开发的人都应该理解这些设计模式，这是成为技术大拿的基础，要不然真的只能算是码农了，各种优秀的开源框架也都大量地应用了这些设计模式，所以这也是我们阅读开源框架源码的基础。如何你够牛的话，你也可以根据自己的经验来总结出一套设计模式。到时可能就是23+种设计模式了。在总结编程设计模式的时候，大牛们又是根据六大原则来总结的。以下用最短的文字总结介绍着六大基本原则。其实六大基本原则和设计模式并不是很复杂的东西，网上有些洋洋洒洒长篇大论，其实我感觉是把简单的问题复杂化。

设计模式六大原则（1）：单一职责原则

很好理解，字面上的意思就是同一个类只做一件事，不要把一个类的多种功能揉在一起，比如说筷子类用来夹东西，勺子类用来舀东西，你不能创建一个类既然当筷子又能当勺子。从这个编程原则来说是不合理的。

单一指责原则也是OOP(面向对象)编程的具体体现。很多时候在面向对象编程的时不知不觉中运用了这种原则。但是有时候我们很难进行指责划分。有时候我们会不断思考这个功能应该是放在这个类还是那个类犹豫不决。所以运用单一职责原则职责划分是重点。

设计模式六大原则（2）：里氏替换原则

官方的定义是如果对每一个类型为S的对象o1， 都有类型为T的对象o2， 使得以T定义的所有程序P在所有的对象o1都代换成o2时， 程序P的行为没有发生变化， 那么类型S是类型T的子类型。

其实里氏替换原则简单来说就是定义了一个接口，接口规范了很多方法子类必须实现。使用的用接口引用。然后当你换一个实现子类的。你的程序不需要修改。

这样做的好处有

● 代码共享， 减少创建类的工作量， 每个子类都拥有父类的方法和属性；

● 提高代码的重用性；

● 子类可以形似父类， 但又异于父类， “龙生龙， 凤生凤， 老鼠生来会打洞”是说子拥有

父的“种”， “世界上没有两片完全相同的叶子”是指明子与父的不同；

● 提高代码的可扩展性， 实现父类的方法就可以“为所欲为”了， 君不见很多开源框架的

扩展接口都是通过继承父类来完成的；

● 提高产品或项目的开放性。

设计模式六大原则（3）：依赖倒置原则

官方的定义

● 高层模块不应该依赖低层模块， 两者都应该依赖其抽象；

● 抽象不应该依赖细节；

● 细节应该依赖抽象。

上面的是不是很难理解，那换种说法

● 模块间的依赖通过抽象发生， 实现类之间不发生直接的依赖关系， 其依赖关系是通过

接口或抽象类产生的；

● 接口或抽象类不依赖于实现类；

● 实现类依赖接口或抽象类。

这一原则就是典型的OOD(面向接口编程的具体实现)

依赖倒置原则有三种的具体实现方式

public interface Food {
 
}

欢迎大家来到IT世界,在知识的湖畔探索吧!

Food 的实现由Rice，Meat。

①构造函数传递依赖

欢迎大家来到IT世界,在知识的湖畔探索吧!public class Eat implements IEat {
 private Food food;
 public Eat(Food food){
 this.food = food;
 }
 @Override
 public void eating() {
 food.food();
 }
}

②setting方法传递依赖

public class Eat implements IEat {
 private Food food;
 public void setFood(Food food){
 this.food = food;
 }
 @Override
 public void eating() {
 food.food();
 }
}

③接口方法传递依赖

欢迎大家来到IT世界,在知识的湖畔探索吧!public class Eat implements IEat {
 
 @Override
 public void eating(Food food) {
 food.food();
 }
}

设计模式六大原则（4）：接口隔离原则

官方的定义：

①客户端不应该依赖它不需要的接口。

②类间的依赖关系应该建立在最小的接口上。

怎么理解呢，我们定义一个接口方法尽可能少，粒度尽可能小，它不依赖其他接口独立完成一个功能或一件事情。接口之间的个功能不应该相互依赖。接口的设计要求本来也是高内聚低耦合。当客户端功能粒度大时，我们可能引用多个接口完成。

隔离原则在实际过程存在问题是，有些时候我们很难把握一个度，为什么，你的接口粒度越小，拆分的越多，整个项目的可读性，可维护就越差，所以这得根据我们平时的积累的经验和实际情况出发来运用这一原则。

设计模式六大原则（5）：迪米特法则

通俗的讲一个对象实体应当尽可能少地与其他对象发生相互作用。

一个类应该对自己需要耦合或者调用的类知道最少， 类的内部如何实现与调用者或者依赖关系越密切，耦合度越大，当一个类发生变化时，对另一个类的影响也越大。

①在类的划分上，应当尽量创建松耦合的类。类之间的耦合度约低，就越有利于服用。一个处于松耦合中的类一旦被修改，则不会对关联的类造成太大的波及。

②在类的机构设计上， 每一个类都应当尽量降低其成员变量和成员函数的访问权限。

③在对其他类的引用上， 一个类对其他对象的引用应当降到最低。

设计模式六大原则（6）：开闭原则

一个软件实体应该通过扩展来实现变化， 而不是通过修改已有的代码来实现变化。类、模块、函数等应该是可以拓展的，但是不可修改。

那什么又是软件实体呢？ 软件实体包括以下几个部分：

● 项目或软件产品中按照一定的逻辑规则划分的模块。

● 抽象和类。

● 方法。

参考书籍：设计模式之禅