设计模式6大原则简约版

单一职责原则（Single Responsibility Principle）

定义

最直白的定义，就是一个类只负责一项职责

问题

可能都会觉得这个没什么的，很容易做到，但就是存在一种叫做职责扩散的问题：A类本来只负责一项职责a，然后有一天a要被细化成两个职责b，c，这个时候大多数人会觉得重新创建类实现b，c比较麻烦，所以就直接在A中做了改动，这就违背了单一职责原则，如果有一天，还要细化职责，还要再加吗，这会是个无底洞！所以编程时，遵守单一职责会让你的代码更加简练，纯洁，不易出问题

好处

1.      降低类的复杂性，利于维护

2.      提高可读性，想想，一个类要是有多个职责，看起来那得多费劲啊

3.      降低变更引起的风险，如果有多个职责，你敢保证修改其中一个不会影响其他的功能？

里氏替换原则（Liskov Substitution Principle）

名字来由

在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的

定义

最直白的话就是，子类可以扩展父类的功能，但不要改变父类原有的功能

原因

对于继承来说的话，父类中已经实现的方法，其实是设定了一系列默认的规范和契约，子类可以不遵从这些规定，但也不能改变它们，如果子类改变父类已经实现的方法，那么就会对达成的契约造成破坏，没有规定可言，无规矩不成方圆，如果你坚持一些不好的编程习惯，那么造成的后果就是，你写的代码出问题的概率会大大上升

 

依赖倒置原则（Dependence Inversion Principle）

定义

直白来说，就是让我们面向接口编程，要依赖于接口或者抽象类，不要依赖于具体实现类

原因：为什么要依赖抽象的东西，而不依赖具体的东西呢，因为抽象的东西比较稳定，而具体的东西更容易发生变化，如果依赖于具体类，那么我们的系统结构就会极不稳定；而且依赖于抽象类或者接口，也会让程序的耦合性更低，稳定性更高

最好做到

1.      使用继承的时候，遵循里氏替换原则

2.      变量（自己写的类）的声明类型最好是抽象类或者接口，这样的话利于扩展和稳定

3.      我们具体的实现类最好都有继承抽象类或者实现接口

接口隔离原则（Interface Segregation Principle）

定义

实现类不要依赖它不需要的接口，也就是说，一个类对另一个类的依赖要建立在最小的接口上

解决：将接口进行拆分，具体类依赖它所需要的接口，这样减少无用的代码，是你的代码更加清爽

启发

1.      不要建立规模庞大，体系臃肿的接口，接口尽量简化，这样会使实现类更好操作

2.      但也不要造成接口太小，这样会使接口数量过多，使程序设计更加复杂，所以这个要根据业务的复杂性适度定义接口

迪米特法则（Law Of Demeter）

定义

迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的IanHolland提出。最直白来说，就是要保持类与类之间最低的耦合性

问题

可以保持低耦合性，但是要通信，就必须要通过类似中介来发生联系。如果过度使用迪米特法则，就会产生大量的中介类，也会导致系统的复杂性变高，所以使用此原则时，要反复权衡，既做到结构清晰，又要做到高内聚低耦合

 

开闭原则（Open Close Principle）

定义

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。这是面向对象设计中最基础的原则

解决

当软件需要变化的时候，尽量通过扩展软件来实现变化，不要改变已有的代码来实现

理解

1.      开闭原则就是：用抽象构建框架，用实现扩展细节

2.      引用别人的话，很经典：“

前面说的5项原则，恰恰是告诉我们用抽象构建框架，用实现扩展细节的注意事项而已：单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。

   最后说明一下如何去遵守这六个原则。对这六个原则的遵守并不是是和否的问题，而是多和少的问题，也就是说，我们一般不会说有没有遵守，而是说遵守程度的多少。任何事都是过犹不及，设计模式的六个设计原则也是一样，制定这六个原则的目的并不是要我们刻板的遵守他们，而需要根据实际情况灵活运用。对他们的遵守程度只要在一个合理的范围内，就算是良好的设计。”