前言:

设计模式六大设计原则思维导图。

 

1、 单一职责原则

    
单一职责原则的定义:

单一职责原则的英文名称是
Single Responsibility Principle，简称是SRP。**应该有且只有一个原因引起类的变化(There should never be more than one reason for a class to change.)。**打个比方，你设计了一个类IuserInfo,该类里面包含了用户信息和用户行为等信息。这就违背了单一职责原则，因此，**我们应该把用户的信息抽取成一个BO（Business Object，业务对象），把行为抽取成一个Biz（Business Logic，业务逻辑）。**这样才符合单一职责原则。单一职责原则的解读: 符合单一职责原则的类或这接口只有一个原因能够引起其变化，也就是说一个类或这接口只负责处理一件事情。

单一职责原则的优点:

(1)、·类的复杂性降低，实现什么职责都有清晰明确的定义；

(2)、·可读性提高，复杂性降低，那当然可读性提高了；

(3)、·可维护性提高，可读性提高，那当然更容易维护了；

**(4)、**变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的
接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

注意:

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”
都是不可度量的，因项目而异，因环境而异。

单一职责不仅仅适用于
类，接口，还适用于方法，言外之意就是一个方法尽可能的只做一件事情。这是一个很好的习惯。但是
在实际的开发过程中单一职责原则是很难百分百的实现的。
但是力求能够做到接口的设计一定要满足单一职责原则，但是类的设计
实现尽量满足单一职责，只有一个原因能够引起其变化。

2、里氏替换原则

Java使用extends关键字来实现继承，它采用了单一继承的规则，C++则采用了多重继承的规则，一个子类可以继承多个父类。
从整体上来看，利大于弊，怎么才能让“利”的因素发挥最大的作用，同时减少“弊”带来的麻烦呢？解决方案是引入
里氏替换原则
（Liskov Substitution Principle，LSP），什么是里氏替换原则呢？它有两种定义：

 (1)、·第一种定义，也是最正宗的定义：

If for each object ol of type S there is an object o2 of type T such that for all programs P defined in terms of T，the behavior of P is unchanged when ol is substituted for o2 then S is a subtype ofT.（
如果对每一个类型为S的对象O1，都有类型为T的对象02，使得以T定义的所有程序P在所有的对象01都代换成02时，程序P的行为没有发生变化，那么类型S是类型T的子类型。）

 (2)、第二种定义：

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.（
所有引用基类的地方必须能透明地使用其子类的对象。） 第二个定义是最清晰明确的，通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。

  
** 里氏代换原则的规则:**

** 1)、子类必须完全实现父类的方法;**
注意1：在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。 注意2：如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

2)、子类可以有自己的个性;
里氏代换原则说明，有父类出现的地方，将子类替换成父类也是OK的，反之，有子类出现的地方，将子类替换成父类则未必
OK。

3)、覆盖或实现父类的方法时输入参数可以被放大;

子类方法的前置条件必须与超类的前置条件(也就是入参:方法的参数)相同或者更宽松。打个比方，父类方法A的前置条件是HashMap，那么子类相同方法的前置条件至少也是HashMap，也可以是一个Map接口。

** (4)、覆写或实现父类的方法时输出结果可以被缩小**

这是什么意思呢，父类的一个方法的返回值是一个类型T，子类的相同方法（重载或覆写）的返回值为S，那么里氏替换原则 就要求S必须小于等于T，也就是说，要么S和T是同一个类型，要么S是T的子类，为什么呢？分两种情况，如果是覆写，父类和子 类的同名方法的输入参数是相同的，两个方法的范围值S小于等于T，这是覆写的要求，这才是重中之重，子类覆写父类的方法， 天经地义。如果是重载，则要求方法的输入参数类型或数量不相同，在里氏替换原则要求下，就是子类的输入参数宽于或等于父类的输入参数，也就是说你写的这个方法是不会被调用的，参考上面讲的前置条件。

采用里氏替换原则的目的就是增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑，非常完美！ 在项目中，采用里氏替换原则时，尽量避免子类的“个性”，一旦子类有“个性”，这个子类和父类之间的关系就很难调和了，把子类当做父类使用，子类的“个性”被抹杀——委屈了点；把子类单独作为一个业务来使用，则会让代码间的耦合关系变得扑朔迷离—— 缺乏类替换的标准。

3、依赖倒置原则

依赖倒置原则（Dependence Inversion Principle，DIP）。High level modules should not depend upon low level modules.Both 
should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.
**    该定义主要包含以下三层含义:**

(1)、 ·高层模块不应该依赖低层模块，两者都应该依赖其抽象；

(2)、 ·抽象不应该依赖细节；

(3)、·细节应该依赖抽象。

高层模块和低层模块容易理解，每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。那什么是抽象？什么又是细节呢？在Java语言中，
抽象就是指接口或抽象类，两者都是不能直接被实例化的；
细节就是实现
类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字
new产生一个对象。

依赖倒置原则在Java语言中的表现就是：

(1)、 ·模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；

(2)、·接口或抽象类不依赖于实现类；

(3)、 ·实现类依赖接口或抽象类。

      ** 依赖倒置原则更加精简的定义就是“面向接口编程”—OOD（Object-Oriented Design，面向对象设计）的精髓之一。**

    依赖的三种写法:
依赖是可以传递的，A对象依赖B对象，B又依赖C，C又依赖D…生生不息，依赖不止，记住一点：只要做到抽象依赖，即使是多层的依赖传递也无所畏惧！对象的依赖关系有三种方式来传递，如下所示。

      
** (1)、构造函数传递依赖对象**
在类中通过构造函数声明依赖对象，按照依赖注入的说法，这种方式叫做构造函数注入，按照这种方式的注入。可以联想Spring
IOC的构造注入。

        
** (2)、Setter方法传递依赖对象**
在抽象中设置Setter方法声明依赖关系，依照依赖注入的说法，这是Setter依赖注入，按照这种方式的注入。Spring中IOC也有
设值注入方式。

** (3)、接口声明依赖对象**
在接口的方法中声明依赖对象，这也叫做接口注入。就是和我们使用Spring的时候使用相关注解注入的方式(@Autowired,@Resource)。

    
*依赖倒置原则总结:    ***
依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：
**  (1)、 ·每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。

(2)、·变量的表面类型尽量是接口或者是抽象类

(3)、·任何类都不应该从具体类派生

(4)、·尽量不要覆写基类的方法如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。

(5)、·结合里氏替换原则使用 接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

***    注意: ***
**依赖倒置原则是6个设计原则中最难以实现的原则，它是实现开闭原则的重要途径，依赖倒置原则没有实现，就别想实现对扩展开放，对修改关闭。**在项目中，大家只要记住是“面向接口编程”就基本上抓住了依赖倒置原则的核心。        

4、接口隔离原则:

在Java中接口分为两种:

 (1)、·实例接口（Object Interface），在Java中声明一个类，然后用new关键字产生一个实例，它是对一个类型的事物的描述，这是一种接口。比如你定义Person这个类，然后使用Person zhangSan=new Person）产生了一个实例，这个实例要遵从的标准就是Person这个类，Person类就是zhangSan的接口。疑惑？看不懂？不要紧，那是因为让Java语言浸染的时间太长了，只要知道从这个角度来看，Java中的类也是一种接口。

(2)、·类接口（Class Interface），Java中经常使用的interface关键字定义的接口。

    主角已经定义清楚了，那什么是隔离呢？它有两种定义，如下所示：

a、·Clients should not be forced to depend upon interfaces that they don't use.（客户端不应该依赖它不需要的接口。）

b、·The dependency of one class to another one should depend on the smallest possible interface.（类间的依赖关系应该建立在最小的接口上。）建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。 把一个臃肿的接口变更为两个独立的接口所依赖的原则就是接口隔离原则，接口是我们设计时对外提供的契约，通过分散定义多个接口，可以预防未来变
更的扩散，提高系统的灵活性和可维护性。接口隔离原则是对接口进行规范约束，其包含以下4层含义：

** (1)、接口要尽量的小**
这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度的，首先就是不能违反单一职责原则，根据接口隔离原则拆分接口时，首先必须满足单一职责原则。

(2)、接口要高内聚
什么是高内聚？高内聚就是提高接口、类、模块的处理能力，减少对外的交互。具体到接口隔离原则就是，要求在接口中尽量少公布public方法，接 口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。

       (3)、·定制服务
一个系统或系统内的模块之间必然会有耦合，有耦合就要有相互访问的接口（并不一定就是Java中定义的Interface，也可能是一个类或单纯的数据交换） ，我们设计时就需要为各个访问者（即客户端）定制服务，什么是定制服务？定制服务就是单独为一个个体提供优良的服务。我们在做系统设计时也需要考虑对系统之间或模块之间的接口采用定制服务。采用定制服务就必然有一个要求：只提供访问者需要的方法。

(4)、接口设计是有限度的
接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低，这不是一个项目或产品所期望看到的，所以接口设计一定要注意适度，这个“度”如何来判断呢？根据经验和常识判断，没有一个固化或可测量的标准。

*** 接口隔离原则总结:***
接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。但是，这个原子该怎么划分是设计模式中的一大难题，在实践中可以根据以下几个规则来衡量：

(1)、 ·一个接口只服务于一个子模块或业务逻辑；

 (2)、·通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；

 (3)、·已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理；

 (4)、·了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的你就照抄。千万别，环境不同，接口拆分的标准就不同。深入了解业务逻辑，
最好的接口设计就出自你的手中！

5、迪米特法则的定义(最少知道原则)

迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least Knowledge Principle，LKP），虽然名字不同，但描述的是同一个规则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。

 迪米特法则对类的低耦合提出了明确的要求，其包含以下4层含义。

(1)、 值和朋友交流
迪米特法则还有一个英文解释是：Only talk to your immediate friends（只与直接的朋友通信。）什么叫做直接的朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等。
注意一个类只和朋友交流，不与陌生类交流，不要出现getAO.getBO.getCO.getDO这种情况（在一种极端的情况下允许出现这种访问，即每一个点号后面的返 回类型都相同），类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象，当然，JDKAPI提供的类除外。

 
(2)、朋友之间也是有距离的
一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。因此，为了保持朋友类间的距离，在设计时需要反复衡量：是否还可以再减少public方法和属性，是否可以修改为private、package-private（包类型，在类、方法、变量前不加访问权限，则默认为包类型）、protected等访问权限，是否可以加上final关键字等。
注意迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected 等访问权限。

  
** (3)、 是自己的就是自己的**
在实际应用中经常会出现这样一个方法：放在本类中也可以，放在其他类中也没有错，那怎么去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

  
** (4)、谨慎使用Serializable**

 在实际应用中，这个问题是很少出现的，即使出现也会立即被发现并得到解决。是怎么回事呢？举个例子来说，在一个项目中使用RMT（Remote Method Invo cation，远程方法调用）方式传递一个VO（Value Object，值对象），这个对象就必须实现Serializable接口（仅仅是一个标志性接口，不需要实现具体的方法） ，也就是把需要网络传输的对象进行序列化，否则就会出现NotSerializableException异常。

迪米特法则的总结:
迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。读者在采用迪米特法则时需要反复权衡，既做到让结构清晰，又做到高内聚低耦合。

6、开闭原则

***开闭原则的定义: ***
Software entities like classes，modules and fimctions should be open for extension but closed for modifications.（一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。）

        我们做一件事情，或者选择一个方向，一般需要经历三个步骤：What——是什么，Why——为什么，How——怎么做（简称3W原则，How取最后一个w）。对于开闭原则，我们 也采用这三步来分析，即什么是开闭原则，为什么要使用开闭原则，怎么使用开闭原则。

设计模式六大原则总结:

 软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的。我们要为不可预料的事情做好准备，这本身就是一件非常痛苦的事情，但是大师
们还是给我们提出了非常好的6大设计原则以及23个设计模式来“封装”未来的变化，我们在前面讲过如下设计原则。

·Single Responsibility Principle：单一职责原则

** ·Open Closed Principle：开闭原则**

** ·Liskov Substitution Principle：里氏替换原则**

** ·Law of Demeter：迪米特法则**

** ·Interface Segregation Principle：接口隔离原则**

·Dependence Inversion Principle：依赖倒置原则

    把这6个原则的首字母（里氏替换原则和迪米特法则的首字母重复，只取一个）联合起来就是SOLID（solid，稳定的），其代表的含义也就是把这6个原则结合使用的好处：建立稳定、灵活、健壮的设计，而开闭原则又是重中之重，是最基础的原则，是其他5大原则的精神领袖。我们在使用开闭原则时要注意以下几个问题。

    
·开闭原则也只是一个原则
开闭原则只是精神口号，实现拥抱变化的方法非常多，并不局限于这6大设计原则，但是遵循这6大设计原则基本上可以应对大多数变化。因此，我们在项目中应尽量 采用这6大原则，适当时候可以进行扩充，例如通过类文件替换的方式完全可以解决系统中的一些缺陷。大家在开发中比较常用的修复缺陷的方法就是类替换，比如一个 软件产品已经在运行中，发现了一个缺陷，需要修正怎么办？如果有自动更新功能，则可以下载一个.class文件直接覆盖原有的class，重新启动应用（也不一定非要重新启动）就可以解决问题，也就是通过类文件的替换方式修正了一个缺陷，当然这种方式也可以应用到项目中，正在运行中的项目发现需要增加一个新功能，通过修改原有实现类的方式就可以解决这个问题，前提条件是：类必须做到高内聚、低耦合，否则类文件的替换会引起不可预料的故障。

******

*** ·项目规章非常重要***
如果你是一位项目经理或架构师，应尽量让自己的项目成员稳定，稳定后才能建立高效的团队文化，章程是一个团队所有成员共同的知识结晶，也是所有成员必须遵守的约定。优秀的章程能带给项目带来非常多的好处，如提高开发效率、降低缺陷率、提高团队士气、提高技术成员水平，等等。

**  **

** ·预知变化**
在实践中过程中，架构师或项目经理一旦发现有发生变化的可能，或者变化曾经发生过，则需要考虑现有的架构是否可以轻松地实现这一变化。架构师设计一套系统
不仅要符合现有的需求，还要适应可能发生的变化，这才是一个优良的架构。
开闭原则是一个终极目标，任何人包括大师级人物都无法百分之百做到，但朝这个方向努力，可以非常显著地改善一个系统的架构，真正做到“拥抱变化”。