《设计模式之美》第三章 总结

《设计模式之美》总结

第三章 设计原则

3.1 单一职责原则：如何判定某个类的职责是否单一

3.1.1 单一职责原则的定义和解读

定义：一个类或模块只负责完成一个职责（功能）
含义：不要设计功能大而全的类或模块，否则要拆成粒度小的类或模块；

3.1.2 如何判断类的职责是否单一

在不同的应用场景和不同阶段的需求背景下，同一个类的职责是否单一的判定可能不一样
在不同业务场景下，同一个类的职责是否单一的判定可能不一样
判定原则：
1. 如果类中的代码行数、函数或属性过多，影响代码的**可读性和可维护性**，就需要考虑对类进行拆分；
2. 如果某个类依赖的其他类过多，或者依赖某个类的其他类过多，不符合**高内聚、低耦合**的代码设计思想，就要考虑拆分；
3. 如果类中的私有方法过多，就需要将私有方法独立到新的类中，并设置为public方法，供更多的类使用，从而**提高代码的复用性**；
4. 如果类很难准确命名（很难用一个业务名词概括），或者只能**笼统命名**，就说明类的职责定义不够清晰；
5. 如果类中的大量方法**集中操作其中的几个属性**，可以考虑将这些属性和对应的方法拆分出来；

3.1.3 类的职责是否越细化越好

设计原则和设计模式的最终目的都是为了提高代码的可读性、可扩展性、复用性和可维护性等。判断使用某一设计原则是否合理时，可以以此作为最高的评价标准。

3.2 开闭原则：只要修改代码，就一定违反开闭原则吗

3.2.1 如何理解“对扩展开放，对修改关闭”

开闭原则是最难理解最难把握的原则，又是最有用的；
大部分设计模式都是为了解决代码的扩展性问题而产生的，它们主要遵守的设计原则就是开闭原则；
定义：添加一个新功能时应该是在已有代码基础上扩展代码（新增模块、类和方法等），而非修改已有的代码（模块、类、方法等）

3.2.2 修改代码就意味着违反开闭原则吗

添加一个新功能时，不可能做到任何模块、类和方法的代码都不“修改”；
原则：尽量让修改操作集中在上层代码中，尽量让核心、复杂、通用、底层的那部分代码满足开闭原则；

3.2.3 如何做到“对扩展开放，对修改关闭”

方法：
1. 需要具备扩展意识、抽象意识和封装意识，这些意识可能比任何技巧都重要；
2. 编码前多花时间思考：未来可能有哪些需求的变更；设计代码结构，预留扩展点；
3. 善于识别代码中可变部分和不可变部分：将可变部分封装，达到隔离的效果，并提供抽象化的不可变接口给上层系统调用；当实现变化时，只需要基于相同的抽象接口扩展新的实现，替换旧的实现，上层系统的代码几乎不需要修改；
4. 大部分设计模式都是为了解决扩展性问题，以开闭原则作为指导原则而设计的；
5. 具体包括：多态、依赖注入、基于接口而非实现编程、大多数设计模式；

3.2.4 如何在项目中灵活应用开闭原则

如何识别代码的扩展点：
1. 对于短期可能实现的扩展，需求改动对代码结构影响比较大的扩展，或实现成本不太大的扩展，可以事先进行可扩展性设计，反之等到有需求驱动时通过重构方式来实现扩展的需求
2. 扩展性会影响可读性；

3.3 里氏替换原则：什么样的代码才是违背里氏替换原则

3.3.1 里氏替换原则的定义

定义：子类对象能投替换到程序中父类对象出现的任何地方，并且保证程序原有的逻辑行为不变和正确性不被破坏；

3.3.2 里氏替换原则与多态的区别

多态是一种代码实现思路，里氏替换原则是一种设计原则，用来指导继承关系中子类的设计：在替换父类时，确保不改变程序原有的逻辑行为，以及不破坏程序的正确性；

3.3.3 违反里氏替换原则的反模式

在设计子类时，需要遵守父类的行为约定（或称为协议），子类可以改变函数内部实现逻辑，但不能改变函数原有的行为约定，包括：函数要实现的功能、对输入、输出和异常的约定，以及对注释中罗列的任何特殊情况的说明等，反之则违反里氏替换原则；
这里的继承也可以替换成接口
测试是否违反里氏替换原则：用父类的单元测试验证子类的代码，看是否运行失败；

3.4 接口隔离原则：如何理解该原则中的“接口”

定义：客户端不应该被强迫依赖它不需要的接口；

3.4.1 把接口理解为一组API或函数

如果部分接口或函数只被部分调用者使用，就需要将这部分接口或函数隔离出来，并单独提供给对应的调用者使用，而不是强迫其他调用者也依赖这部分不会被用到的接口或函数；

3.4.2 把接口理解为单一API或函数

和单一职责原则有点类似，使用接口隔离原则判断接口职责是否单一：通过调用者如何使用接口来间接地判定接口是否职责单一，

3.4.3 把接口理解为OOP中的接口概念

3.5 依赖反转原则：依赖反转与控制反转、依赖注入有何关系

3.5.1 控制反转（IOC）

“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己编写代码控制整个程序的执行流程。在使用框架之后，整个程序的执行流程由框架控制，流程的控制权从程序员“反转”给了框架；
实现方式：模板设计模式、依赖注入等
是一种比较笼统的设计思想，一般用来指导框架的设计；

3.5.2 依赖注入（DI）

依赖注入是一种具体的编程技巧；
定义：不通过new的方式在类内部创建依赖的类对象，将依赖的类对象在外部创建好之后，通过构造函数、参数等方式传递（或称注入）给类使用；
是编写可测试性代码的有效手段；

3.5.3 依赖注入框架（DI Framework）

依赖注入框架提供扩展点，简单配置所有需要创建的类对象、类之间的依赖关系，就可以实现框架自动创建对象、管理对象生命周期、依赖注入等功能；

3.5.4 依赖反转原则（DIP）

用好比较简单，理解比较难
也叫依赖倒置原则：高层模块不要依赖低层模块，高层模块和低层模块应该通过抽象互相依赖，以及抽象不要依赖具体实现细节，具体实现细节依赖抽象；
高层模块：调用者；
低层模块：被调用者；
Tomcat和应用程序之间的关系举例：tomcat是调用者，属于高层；应用程序是被调用者，属于低层；二者之间没有直接的依赖，二者之间依赖于Servlet规范；Servlet规范不依赖于Tomcat容器和应用程序的实现细节；
用处：用例指导框架设计；

3.6 KISS原则和YAGNI原则：二者是一回事吗

3.6.1 KISS原则的定义和解读

定义：尽量保持简单；
KISS原则是保持代码可读性、可维护性的重要手段；

3.6.2 代码并非行数越少越简单

3.6.3 代码复杂不一定违反KISS原则

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

1. 慎重使用过于复杂的技术来实现代码，如复杂的正则表达式、编程语言中过于高级的语法等；
2. 不要“重复造轮子”，首先考虑使用已有类库；
3. 不要过度优化，尽量避免使用一些“奇技淫巧”；

3.6.5 YAGNI原则和KISS原则的区别

含义：不要去设计当前用不到的功能，不要去编写当前用不到的代码；核心是：不要过度设计；

3.7 DRY原则：相同的两段代码就一定违反DRY原则吗

定义：不要编写重复的代码

3.7.1 代码逻辑重复

可以通过抽取更细粒度的函数的方式来解决；

3.7.2 功能（语义）重复

3.7.3 代码执行重复

3.7.4 代码的复用性

提高复用性的方法：
1. 降低代码的耦合度；
2. 满足单一职责原则：代码的粒度越细，其通用性越好，越容易复用；
3. 将代码模块化；
4. 业务逻辑和非业务逻辑分离；
5. 通用代码“下沉”；
6. 继承、封装、抽象、多态：越抽象的代码越容易被复用；
7. 应用模板等设计模式；
8. 具备复用的意思最重要；
9. “Rule of Three”原则：第一次编写代码时，不考虑复用性，在之后遇到复用场景时，在重构，使其可以复用；

3.8 LoD: 如何实现代码的“高内聚，低耦合”

迪米特法则

3.8.1 何为“高内聚，低耦合”

高内聚、低耦合是一个非常重要的设计思想，一个通用的设计思想；
作用：有效提高代码的可读性和可维护性，缩小功能改动引起的代码改动范围；
实现原则：单一职责原则、基于接口而非实现编程；
使用范围：指导系统、模块、类、函数的设计开发，以及微服务、框架、组件和类库等的设计开发；
举例：在类设计中，高内聚：用来指导类本身的设计，相近功能放到同一个类中，不相近的不要放到同一个类中；低耦合：用来指导类之间依赖关系的设计，类之间的依赖关系要简单清晰；
关联：高内聚有助于低耦合，低内聚会导致高耦合；

3.8.2 LoD的定义描述

定义：最少知识原则，每个模块只应该了解那些与它关系密切的模块的有限知识；

3.8.3 定义解读

解读：不应该存在直接依赖关系的类之间不要有依赖，有依赖关系的类之间尽量只依赖必要的接口；