JavaScript设计原则
单一职责原则（SRP）
Single Responsibility Principle
单一职责原则的职责被定义为“引起变化的原因”。如果我们有两个动机去改写一个方法，那么这个方法就具有两个职责。每个职责都是变化的一个轴线，如果一个方法承担了过多的职责，那么在需求的变迁过程中，需要改写这个方法的可能性就越大。一个对象（方法）只做一件事情。
优点：降低了单个类或者对象的复杂度，按照职责把对象分解成更小的粒度，这有助于代码的复用，也有利于进行单元测试。当一个职责需要变更的时候，不会影响到其他的职责。
缺点：增加编码复杂度，同时增加对象之间联系的难度
开放-封闭原则（OCP）
Open Closed Principle
软件实体（类、模块、函数）等应该是可以扩展的，但是不可修改。
当需要改变一个程序的功能或者给这个程序增加新功能的时候，可以使用增加代码的方式，但是不允许改动程序的源代码。
- 找出变化的地方
- 用对象的多态性消除条件分支
- 放置挂钩
- 使用回调函数
优点：程序的稳定性提升、容易变化的地方分离出来后更容易维护
缺点：代码的完全封闭几乎不可能
最少知识原则（LKP）
Least Knowledge Principle
最少知识原则说的是一个软件实体应当尽可能少地与其他实体发生相互作用。如果两个对象之间不必彼此直接通信，那么这两个对象就不要发生直接的相互联系。常见的做法是引入一个第三者对象，来承担这些对象之间的通信作用。如果一些对象需要向另一些对象发起请求，可以通过第三者对象来转发这些请求。
优点：减少或消除对象之间的耦合程度，提高复用性
缺点：需要封装对象或者引入一个第三者对象来处理两者之间的联系，有时候第三者对象会复杂到难以维护。
里氏替换原则（LSP）
Liskov Substitution Principle
所有引用基类的地方必须能透明地使用其子类的对象
接口隔离原则（ISP）
Interface Segregation Principle
1、客户端不应该依赖它不需要的接口。
2、类间的依赖关系应该建立在最小的接口上。
依赖倒置原则（DIP）
Dependence Inversion Principle
1、上层模块不应该依赖底层模块，它们都应该依赖于抽象。
2、抽象不应该依赖于细节，细节应该依赖于抽象。
