设计原则

单一职责原则

• 定义
  单一职责原则（Single Responsibility Principle，SRP），指一个类或者模块只负责完成一个职责（或者说功能）。也就是说，不要设计大而全的类，要设计粒度小、功能单一的类。
• 判定原则

1. 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性，我们就需要考虑对类进行拆分；
2. 类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想，我们就需要考虑对类进行拆分；
3. 私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性；
4. 比较难给类起一个合适名字，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context 之类的词语来命名，这就说明类的职责定义得可能不够清晰；
5. 类中大量的方法都是集中操作类中的某几个属性，比如，在 UserInfo 例子中，如果一半的方法都是在操作 address 信息，那就可以考虑将这几个属性和对应的方法拆分出来

• 一定是越单一越好吗？
  单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、低耦合。但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。

开闭原则

• 定义
  开闭原则（Open Closed Principle，OCP），添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。关于定义，我们有两点要注意。第一点是，开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。第二点是，同样的代码改动，在粗代码粒度下，可能被认定为“修改”；在细代码粒度下，可能又被认定为“扩展”。
• 方法论

1. 我们要时刻具备扩展意识、抽象意识、封装意识。在写代码的时候，我们要多花点时间思考一下，这段代码未来可能有哪些需求变更，如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，在不改动代码整体结构、做到最小代码改动的情况下，将新的代码灵活地插入到扩展点上。
2. 很多设计原则、设计思想、设计模式，都是以提高代码的扩展性为最终目的的。特别是 23 种经典设计模式，大部分都是为了解决代码的扩展性问题而总结出来的，都是以开闭原则为指导原则的。最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态）。

里氏替换原则

• 定义
  里氏替换原则（Liskov Substitution Principle，LSP），子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。
• 方法论

1. 子类不能违背父类声明要实现的功能；
2. 子类不能违背父类对输入、输出、异常的约定，其中异常是容易在设计中忽略的点；
3. 子类不能违背父类注释中所罗列的任何特殊说明；
4. 改进抽象设计。如果一个子类中的实现违反了LSP，那么是不是考虑抽象或者设计出了问题。

接口隔离原则

• 定义
  接口隔离原则（Interface Segregation Principle，ISP）。

1. 如果把“接口”理解为一组接口集合，可以是某个微服务的接口，也可以是某个类库的接口等。如果部分接口只被部分调用者使用，我们就需要将这部分接口隔离出来，单独给这部分调用者使用，而不强迫其他调用者也依赖这部分不会被用到的接口。
2. 如果把“接口”理解为单个 API 接口或函数，部分调用者只需要函数中的部分功能，那我们就需要把函数拆分成粒度更细的多个函数，让调用者只依赖它需要的那个细粒度函数。
3. 如果把“接口”理解为 OOP 中的接口，也可以理解为面向对象编程语言中的接口语法。那接口的设计要尽量单一，不要让接口的实现类和调用者，依赖不需要的接口函数。

• 方法论

1. 不强迫其他调用者也依赖这部分不会被用到的接口；
2. 让调用者只依赖它需要的那个细粒度函数；
3. 不要让接口的实现类和调用者，依赖不需要的接口函数

控制反转原则

• 定义：控制反转（Inversion Of Control，IOC），实际上，控制反转是一个比较笼统的设计思想，并不是一种具体的实现方法，一般用来指导框架层面的设计。这里所说的“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程通过框架来控制。流程的控制权从程序员“反转”给了框架。
• 方法论：通过一些手段（如依赖注入）达到控制反转的目的可以使软件的设计上更加合理

依赖倒转原则

• 定义：依赖倒转原则（Dependency Inversion Principle，DIP），依赖反转原则也叫作依赖倒置原则。这条原则跟控制反转有点类似，主要用来指导框架层面的设计。高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。
• 方法论：依赖抽象而不是依赖实现

KISS原则

• 定义：Keep It Simple and Stupid. 尽量保持简单。
• 方法论：

1. 不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等；
2. 不要重复造轮子，要善于使用已经有的工具类库。经验证明，自己去实现这些类库，出 bug 的概率会更高，维护的成本也比较高；
3. 不要过度优化。不要过度使用一些奇技淫巧（比如，位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性
4. 把复杂的事情做简单才是能力的体现；

YAGNI 原则

• 定义：You Ain’t Gonna Need It。不做过度设计。
• 方法论：

1. 留好扩展点，不做过度设计

DRY 原则

• 定义：Don’t Repeat Yourself。不写重复的代码。实现逻辑重复，但功能语义不重复的代码，并不违反 DRY 原则。实现逻辑不重复，但功能语义重复的代码，也算是违反 DRY 原则。除此之外，代码执行重复也算是违反 DRY 原则。
• 方法论：

1. 减少代码耦合；
2. 满足单一职责原则；
3. 模块化；
4. 业务与非业务逻辑分离；
5. 通用代码下沉；
6. 继承、多态、抽象、封装；
7. 应用模板等设计模式

迪米特原则

• 定义：迪米特原则（Law of Demete，LOD），不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。
• 方法论：

1. 不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口

参考资料

1. 极客时间设计—模式之美