设计原则简介
设计原则是指导我们代码设计的一些经验总结。设计原则这块儿的知识有一个非常大的特点，那就是这些原则听起来都比较抽象，定义描述都比较模糊，不同的人会有不同的解读。所以，如果单纯地去记忆定义，对于编程、设计能力的提高，意义并不大。对于每一种设计原则，我们需要掌握它的设计初衷，能解决哪些编程问题，有哪些应用场景。主要包括六大基本原则；
一，单一职责原则
英文全称 Single Responsibility Principle，缩写为 SRP
简介：
一个类或者模块只负责完成一个职责（或者功能）
实现：
一个类只负责完成一个职责或者功能。不要设计大而全的类，要设计粒度小、功能单一的类。单一职责原则是为了实现代码高内聚、低耦合，提高代码的复用性、可读性、可维护性。
判断是否职责是否单一：
类中的代码行数、函数或者属性过多；
类依赖的其他类过多，或者依赖类的其他类过多；
私有方法过多；
比较难给类起一个合适的名字；
类中大量的方法都是集中操作类中的某几个属性。
二，开闭原则
英文全称：Open Closed Principle 简称：OCP
简介：
简单理解就是，“对扩展开放，对修改关闭”；更进一步解释就是，添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。
实现：
常用实现方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态等）。
注意事项：
1，开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。而且有些情况下，代码的扩展性提高了，但是可读性降低了；很多时候，我们都需要在扩展性和可读性之间做权衡。
2，同样的代码改动，在粗代码粒度下，可能被认定为“修改”；在细代码粒度下，可能又被认定为“扩展”。
总结：很多设计原则，设计模式，设计思想把提高代码的扩展性为最终目的；把开闭原则作为指导准则，可想而知开闭原则有多重要；
三，里氏替换原则
英文全称：Liskov Substitution Principle 简写：LSP
简介：
子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。理解里式替换原则，最核心的就是理解“design by contract，按照协议来设计”这几个字。
里氏替换和多态的区别：
多态是面向对象编程的一大特性，也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里式替换是一种设计原则，用来指导继承关系中子类该如何设计，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑及不破坏原有程序的正确性。
判断是否违背里氏替换原则：
1，判断子类的设计实现是否违背里式替换原则，还有一个小窍门，那就是拿父类的单元测试去验证子类的代码。
2，父类定义了函数的“约定”（或者叫协议），那子类可以改变函数的内部实现逻辑，但不能改变函数原有的“约定”。这里的约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。
四，接口隔离原则
英文全称： Interface Segregation Principle 缩写：ISP
简介
客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。
解释
理解接口隔离原则，关键是理解“接口”；接口解释有以下两种，1，如果把“接口”理解为单个 API 接口或函数，部分调用者只需要函数中的部分功能，那我们就需要把函数拆分成粒度更细的多个函数，让调用者只依赖它需要的那个细粒度函数。2，如果把“接口”理解为 OOP 中的接口，也可以理解为面向对象编程语言中的接口语法。那接口的设计要尽量单一，不要让接口的实现类和调用者，依赖不需要的接口函数。
接口隔离和单一职责的区别
单一职责原则针对的是模块、类、接口的设计。接口隔离原则相对于单一职责原则，一方面更侧重于接口的设计，另一方面它的思考角度也是不同的。接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。
五，依赖反转
英文全称： Dependency Inversion Principle 缩写：DIP 依赖反转原则又称依赖倒置原则；
简介
高层模块不要依赖低层模块。高层模块和低层模块应该通过抽象来互相依赖。除此之外，抽象不要依赖具体实现细节，具体实现细节依赖抽象。
六，迪米特法则
英文全称：Law of Demeter，缩写 LOD
简介
不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合，让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化，需要了解这一变化的类就会比较少。
应用
实现高内聚低耦合的代码