Part.2 设计原则

设计模式

1、单一职责原则（SRP）

主要思想：一个类或者模块只负责完成一个职责（或者功能）

1.1 如何判断职责是否单一

• 目前没有非常明确、可以量化的标准，也就是说判断标准可能会随着业务的发展而不同。

1.2 如何设计

• 可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以将这个粗粒度的类，拆分成几个更细粒度的类。这就是所谓的持续重构。

1.3 什么时候需要代码拆分

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

2、开闭原则（OCP）

主要思想：软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”，即在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。

2.1 如何做到开闭原则

• 为了尽量写出扩展性好的代码，我们要时刻具备扩展意识、抽象意识、封装意识。这些“潜意识”可能比任何开发技巧都重要。
• 编程方法：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态等）。

2.2 如何在日常开发中灵活应用开闭原则

• 对于一些比较确定的、短期内可能就会扩展，或者需求改动对代码结构影响比较大的情况，或者实现成本不高的扩展点，在编写代码的时候之后，我们就可以事先做些扩展性设计。但对于一些不确定未来是否要支持的需求，或者实现起来比较复杂的扩展点，我们可以等到有需求驱动的时候，再通过重构代码的方式来支持扩展的需求。

3、里氏替换原则（LSP）

主要思想：子类对象可以替换程序中父类对象。

3.1 哪些代码逻辑违背了里式替换原则

• 子类违背父类声明要实现的功能。
• 子类违背父类对输入、输出、异常的约定。
• 子类违背父类注释中所罗列的任何特殊说明。

4、接口隔离原则（ISP）

主要思想：客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。

4.1 如何理解“接口隔离原则”？

理解“接口隔离原则”的重点是理解其中的“接口”二字。这里有三种不同的理解。

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

5、依赖反转原则（DIP）

主要思想：这条原则跟控制反转有点类似，主要用来指导框架层面的设计。高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。

5.1 如何理解依赖反转原则

• 上层模块依赖接口，下层模块实现接口。

点击展开内容

6、KISS原则

主要思想：代码尽量简单。

6.1 如何写出满足KISS原则的代码

• 不要使用同事可能不懂的技术来实现代码。
• 不要重复造轮子，要善于使用已经有的工具类库。
• 不要过度优化。

7、DRY原则

主要思想：不要写重复的代码。重复主要指实现逻辑重复、功能语义重复和代码执行重复。

8、代码复用性

8.1 如何提高代码复用性

• 减少代码耦合。
• 满足单一职责原则。
• 模块化。
• 业务与非业务逻辑分离。
• 通用代码下沉。
• 继承、多态、抽象、封装。
• 应用模块等设计模式。

9、迪米特法则（LOD）

主要思想：不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。

10、代码分层的意义

1.分层能起到代码复用的作用

同一个Repository可能会被多个Service来调用，同一个Service可能会被多个Controller调用。比如，UserService中的getUserById()接口封装了通过ID获取用户信息的逻辑，这部分逻辑可能会被UserController和AdminController等多个Controller使用。如果没有Service层，每个Controller都要重复实现这部分逻辑，显然会违反DRY原则。

2.分层能起到隔离变化的作用

分层体现了一种抽象和封装的设计思想。比如，Repository层封装了对数据库访问的操作，提供了抽象的数据访问接口。基于接口而非实现编程的设计思想，Service层使用Repository层提供的接口，并不关心其底层依赖的是哪种具体的数据库。当我们需要替换数据库的时候，比如从MySQL到Oracle，从Oracle到Redis，只需要改动Repository层的代码，Service层的代码完全不需要修改。

除此之外，Controller、Service、Repository三层代码的稳定程度不同、引起变化的原因不同，所以分成三层来组织代码，能有效地隔离变化。比如，Repository层基于数据库表，而数据库表改动的可能性很小，所以Repository层的代码最稳定，而Controller层提供适配给外部使用的接口，代码经常会变动。分层之后，Controller层中代码的频繁改动并不会影响到稳定的Repository层。

3.分层能起到隔离关注点的作用

Repository层只关注数据的读写。Service层只关注业务逻辑，不关注数据的来源。Controller层只关注与外界打交道，数据校验、封装、格式转换，并不关心业务逻辑。三层之间的关注点不同，分层之后，职责分明，更加符合单一职责原则，代码的内聚性更好。

4.分层能提高代码的可测试性

后面讲单元测试的时候，我们会讲到，单元测试不依赖不可控的外部组件，比如数据库。分层之后，Repsitory层的代码通过依赖注入的方式供Service层使用，当要测试包含核心业务逻辑的Service层代码的时候，我们可以用mock的数据源替代真实的数据库，注入到Service层代码中。代码的可测试性和单元测试我们后面会讲到，这里你稍微了解即可。

5.分层能应对系统的复杂性

所有的代码都放到一个类中，那这个类的代码就会因为需求的迭代而无限膨胀。我们知道，当一个类或一个函数的代码过多之后，可读性、可维护性就会变差。那我们就要想办法拆分。拆分有垂直和水平两个方向。水平方向基于业务来做拆分，就是模块化；垂直方向基于流程来做拆分，就是这里说的分层。