设计模式之六大原则

　　单一职责原则

　　单一职责原则（Single responsibility principle），就一个类而言，应该只有一个引起它变化的原因。

　　在实际编程中的体现，比如一个类只是某一个事物相关的集合，一个函数只做一件事情，不要在这个函数中编写一些不想关的逻辑，这样可以最大程度的提高程序的可维护性，可复用性。

　　开放-封闭原则

　　开放-封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改，即对扩展是开放的，对修改是关闭的。新的需求，应该通过增加新的代码来完成，而不是修改现有的代码。绝对的对修改关闭是不可能的，可以预先猜测最有可能发生的变化种类，然后构造抽象来隔离那些变化。

　　在实际编程中的体现，比如接手了一个复杂的代码库，要基于此完成某种功能时，如果一上手就咔咔咔大改里面的逻辑，不仅不是正确的做法，有时越改越深入，如果不完全理解这个代码库的大部分逻辑，就不能完成当前的需求，耽误了很长时间，老大肯定会不开心的^_^。

　　依赖倒置原则

　　1. 高层模块不应该依赖底层模块。两个都应该依赖抽象；

　　2. 抽象不应该依赖细节。细节应该依赖抽象。

　　开发程序时，高层模块调用底层模块的函数。当要做新项目时，发现高层模块基本一致，想要复用，但是要换用不同的数据库或者存储方式（底层模块），而高层模块与底层访问数据库的模块绑定了，无法复用，这就出现了倒置。解决办法是不管高层模块还是底层模块，都应该依赖抽象，具体一点就是接口和抽象类。

　　在实际生活当中的应用，比如计算机的主板、CPU、内存、硬盘等都是针对接口设计的，如果针对实现来设计，比如某一个型号的主板只支持某一个型号的CPU，这将会大大制约计算机的发展。在实际编程中的应用，比如，一个部门写了一个lib，其他部门都要使用，那么这些部门就应该相互沟通好，大家先把接口固定，然后各自编写自己的程序，只要接口设计的稳定，这些部门之间就可以自己写自己的程序，不用担心相互干扰。

#

　　里氏代换原则

　　子类型必须能够替换掉它们的父类型。意思是如果一个软件实体使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别，即在软件里面，把父类都替换成它的子类，程序的行为没有变化。再通俗点，如果一个方法需要父类对象作为输入，如果你提供一个子类对象，它也应该正常工作，如果它不能正常工作，那么这种写法就违反了里氏替换原则。

　　迪米特法则

　　迪米特法则，如果两个类不必彼此直接通信，那么这两个类就不应该发生直接的相互作用。如果其中一个类需要调用领一个类的某一个方法的话，可以通过第三者转发这个调用。在类的结构设计上，每一个类都应当尽量降低成员的访问权限，不需要公开的就不要公开，其根本思想是强调了类之间的松耦合。