Bob大叔提出并发扬了S.O.L.I.D五大原则，用来更好地进行面向对象编程，五大原则分别是：
- The Single Responsibility Principle（单一职责SRP）
- The Open/Closed Principle（开闭原则OCP）
- The Liskov Substitution Principle（里氏替换原则LSP）
- The Interface Segregation Principle（接口分离原则ISP）
- The Dependency Inversion Principle（依赖反转原则DIP）
单一职责SRP:
单一职责的描述如下：
A class should have only one reason to change
类发生更改的原因应该只有一个
一个类（JavaScript下应该是一个对象）应该有一组紧密相关的行为的意思是什么？遵守单一职责的好处是可以让我们很容易地来维护这个对象，当一个对象封装了很多职责的话，一旦一个职责需要修改，势必会影响该对象想的其它职责代码。通过解耦可以让每个职责工更加有弹性地变化。
不过，我们如何知道一个对象的多个行为构造多个职责还是单个职责？我们可以通过参考Object Design: Roles, Responsibilies, and Collaborations一书提出的Role Stereotypes概念来决定，该书提出了如下Role Stereotypes来区分职责：
- Information holder – 该对象设计为存储对象并提供对象信息给其它对象。
- Structurer – 该对象设计为维护对象和信息之间的关系
- Service provider – 该对象设计为处理工作并提供服务给其它对象
- Controller – 该对象设计为控制决策一系列负责的任务处理
- Coordinator – 该对象不做任何决策处理工作，只是delegate工作到其它对象上
- Interfacer – 该对象设计为在系统的各个部分转化信息（或请求）
一旦你知道了这些概念，那就很容易知道你的代码到底是多职责还是单一职责了。
开闭原则OCP
开闭原则的描述是：
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
软件实体（类，模块，方法等等）应当对扩展开放，对修改关闭，即软件实体应当在不修改的前提下扩展。
open for extension（对扩展开放）的意思是说当新需求出现的时候，可以通过扩展现有模型达到目的。而Close for modification（对修改关闭）的意思是说不允许对该实体做任何修改，说白了，就是这些需要执行多样行为的实体应该设计成不需要修改就可以实现各种的变化，坚持开闭原则有利于用最少的代码进行项目维护。
里氏替换原则LSP
Liskov于1987年提出了一个关于继承的原则“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“继承必须确保超类所拥有的性质在子类中仍然成立。”也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系。
该原则称为Liskov Substitution Principle——里氏替换原则
接口分离原则ISP
Clients should not be forced to depend upon interfaces that they do not use.
不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。
它包含了2层意思：
- 接口的设计原则：接口的设计应该遵循最小接口原则，不要把用户不使用的方法塞进同一个接口里。
如果一个接口的方法没有被使用到，则说明该接口过胖，应该将其分割成几个功能专一的接口。
- 接口的依赖（继承）原则：如果一个接口a依赖（继承）另一个接口b，则接口a相当于继承了接口b的方法，那么继承了接口b后的接口a也应该遵循上述原则：不应该包含用户不使用的方法。
反之，则说明接口a被b给污染了，应该重新设计它们的关系。
如果用户被迫依赖他们不使用的接口，当接口发生改变时，他们也不得不跟着改变。换而言之，一个用户依赖了未使用但被其他用户使用的接口，当其他用户修改该接口时，依赖该接口的所有用户都将受到影响。这显然违反了开闭原则，也不是我们所期望的。
依赖倒置原则（Dependence Inversion Principle，DIP）的原始定义：
- 高层模块不应该依赖底层模块，两者都应该依赖其抽象；
- 抽象不应该依赖细节；
- 细节应该依赖抽象。