设计模式之美笔记 —— 解耦

设计模式之美 - 30

• “解耦”为何如此重要？如何判定代码是否需要“解耦”？
• 如何给代码“解耦”？

一、解耦的重要性

• 保证代码不会复杂到无法控制
• 提高代码的可读性和可维护性，阅读和修改代码的时候，不需要了解太多其他模块或者类的代码
• 提高可测试性
• 降低某一模块实现效率不高而造成影响的范围

二、如何给代码进行解耦

1、封装和抽象

      可以有效地隐藏实现的复杂性，隔离实现的易变性，给依赖的模块提供稳定且易用的抽象接口。

2、中间层

引入中间层能简化模块或类之间的依赖关系。下面这张图是引入中间层前后的依赖关系对比图。


我们在进行重构的时候，引入中间层可以起到过渡的作用，能够让开发和重构同步进行，不互相干扰。
比如，某个接口设计得有问题，我们需要修改它的定义，同时，所有调用这个接口的代码都要做相应的改动。如果新开发的代码也用到这个接口，那开发就跟重构冲突了。为了让重构能小步快跑，我们可以分下面四个阶段来完成接口的修改。

• 第一阶段：引入一个中间层，包裹老的接口，提供新的接口定义。
• 第二阶段：新开发的代码依赖中间层提供的新接口。
• 第三阶段：将依赖老接口的代码改为调用新接口。
• 第四阶段：确保所有的代码都调用新接口之后，删除掉老的接口。

3、模块化

将每个模块都当作一个独立的 lib 一样来开发，只提供封装了内部实现细节的接口给其他模块使用，这样可以减少不同模块之间的耦合度。

4、实现“高内聚，低耦合”目的的设计原则

• 单一职责原则：职责单一，降低依赖他的和他依赖的类，从而降低耦合度
• 基于接口而非实现编程，通过接口这个中间层，隔离变化和具体的实现
• 依赖注入：依赖注入也是将代码之间的强耦合变为弱耦合。尽管依赖注入无法将本应该有依赖关系的两个类，解耦为没有依赖关系，但可以让耦合关系没那么紧密，容易做到插拔替换。
• 多用组合少用继承
• 最少知道原则：只调用需要的方法