设计模式六大原则
SOLID
设计模式的六大原则有：
Single Responsibility Principle：单一职责原则
Open Closed Principle：开闭原则
Liskov Substitution Principle：里氏替换原则
Law of Demeter：迪米特法则
Interface Segregation Principle：接口隔离原则
Dependence Inversion Principle：依赖倒置原则
把这六个原则的首字母联合起来（ L 算做一个或去掉迪米特法则）就是 SOLID （solid，稳定的），其代表的含义就是这六个原则结合使用的好处：建立稳定、灵活、健壮的设计。
一、单一职责原则（Single Responsibility Principle）
定义
即：一个类只允许有一个职责，即只有一个导致该类变更的原因。
定义的解读
类职责的变化往往就是导致类变化的原因：也就是说如果一个类具有多种职责，就会有多种导致这个类变化的原因，从而导致这个类的维护变得困难。
往往在软件开发中随着需求的不断增加，可能会给原来的类添加一些本来不属于它的一些职责，从而违反了单一职责原则。如果我们发现当前类的职责不仅仅有一个，就应该将本来不属于该类真正的职责分离出去。
不仅仅是类，函数（方法）也要遵循单一职责原则，即：一个函数（方法）只做一件事情。如果发现一个函数（方法）里面有不同的任务，则需要将不同的任务以另一个函数（方法）的形式分离出去。
优点
代码的粒度降低了，类的复杂度降低了。
可读性提高了，每个类的职责都很明确，可读性自然更好。
可维护性提高了，可读性提高了，一旦出现 bug ，自然更容易找到他问题所在。
改动代码所消耗的资源降低了，更改的风险也降低了。
二、开闭原则（Open Close Principle）
定义
即：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
定义的解读
用抽象构建框架，用实现扩展细节。
不以改动原有类的方式来实现新需求，而是应该以实现事先抽象出来的接口（或具体类继承抽象类）的方式来实现。
优点
可以在不改动原有代码的前提下给程序扩展功能。增加了程序的可扩展性，同时也降低了程序的维护成本。
三、迪米特法则（Law of Demeter）
定义
即：一个对象应该对尽可能少的对象有接触，也就是只接触那些真正需要接触的对象。
定义解读
迪米特法则也叫做最少知道原则（Least Know Principle）， 一个类应该只和它的成员变量，方法的输入，返回参数中的类作交流，而不应该引入其他的类（间接交流）。
优点
实践迪米特法则可以良好地降低类与类之间的耦合，减少类与类之间的关联程度，让类与类之间的协作更加直接。‘
实践
在做对象与对象之间交互的设计时，应该极力避免引出中间对象的情况（需要导入其他对象的类）：需要什么对象直接返回即可，降低类之间的耦合度。
四、里氏替换原则（Liskov Substitution Principle）
定义
即：所有引用基类的地方必须能透明地使用其子类的对象，也就是说子类对象可以替换其父类对象，而程序执行效果不变。
定义的解读
在继承体系中，子类中可以增加自己特有的方法，也可以实现父类的抽象方法，但是不能重写父类的非抽象方法，否则该继承关系就不是一个正确的继承关系。
优点
可以检验继承使用的正确性，约束继承在使用上的泛滥。
实践
里氏替换原则是对继承关系的一种检验：检验是否真正符合继承关系，以避免继承的滥用。因此，在使用继承之前，需要反复思考和确认该继承关系是否正确，或者当前的继承体系是否还可以支持后续的需求变更，如果无法支持，则需要及时重构，采用更好的方式来设计程序。
五、接口隔离原则（Interface Segregation Principle）
定义
即：多个特定的客户端接口要好于一个通用性的总接口。
定义解读
客户端不应该依赖它不需要实现的接口。
不建立庞大臃肿的接口，应尽量细化接口，接口中的方法应该尽量少。
需要注意的是：接口的粒度也不能太小。如果过小，则会造成接口数量过多，使设计复杂化。
看起来，该原则与单一职责原则很相像。确实很像，二者都是强调要将接口进行细分，只不过分的方式不同。单一职责原则是按照 职责 进行划分接口的；而接口隔离原则则是按照实现类对方法的使用来划分的。可以说，接口隔离原则更细一些。
优点
避免同一个接口里面包含不同类职责的方法，接口责任划分更加明确，符合高内聚低耦合的思想。
六、依赖倒置原则（Dependency Inversion Principle）
定义
即：依赖抽象，而不是依赖实现。
抽象不应该依赖细节；细节应该依赖抽象。
高层模块不能依赖低层模块，二者都应该依赖抽象。
定义解读
针对接口编程，而不是针对实现编程。
尽量不要从具体的类派生，而是以继承抽象类或实现接口来实现。
关于高层模块与低层模块的划分可以按照决策能力的高低进行划分。业务层自然就处于上层模块，逻辑层和数据层自然就归类为底层。
优点
通过抽象来搭建框架，建立类和类的关联，以减少类间的耦合性。而且以抽象搭建的系统要比以具体实现搭建的系统更加稳定，扩展性更高，同时也便于维护。
