设计原则与思想：设计原则（下）- 理论五 - 八控制反转、依赖反转、依赖注入这三者有何区别和联系？为何说KISS、YAGNI原则为何经常被用错？重复的代码就一定违背DRY吗？如何用迪米特法则？

冲冲冲ccc

已于 2024-08-13 16:20:15 修改

阅读量969

点赞数 24

分类专栏：设计模式文章标签：设计模式

于 2024-08-13 16:15:40 首次发布

本文链接：https://blog.csdn.net/a0987654321abc/article/details/141166877

版权

设计模式专栏收录该内容

9 篇文章 0 订阅

订阅专栏

理论五：控制反转、依赖反转、依赖注入，这三者有何区别和联系？

控制反转（IOC）
- 实际上，控制反转是一个比较笼统的设计思想，并不是一种具体的实现方法，一般用来指导框架层面的设计。这里所说的“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程通过框架来控制。流程的控制权从程序员“反转”给了框架。
依赖注入
- 依赖注入和控制反转恰恰相反，它是一种具体的编码技巧。
- 我们不通过 new 的方式在类内部创建依赖类的对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类来使用。
依赖注入框架
- 我们通过依赖注入框架提供的扩展点，简单配置一下所有需要的类及其类与类之间依赖关系，就可以实现由框架来自动创建对象、管理对象的生命周期、依赖注入等原本需要程序员来做的事情。但是，这个创建对象、组装（或注入）对象的工作仅仅是被移动到了更上层代码而已，还是需要我们程序员自己来实现。
- 好处：new 是硬编码。用了依赖注入将依赖的类对象传递进来，这样就提高了代码的扩展性，我们可以灵活地替换依赖的类。
依赖反转原则（依赖倒置原则）
- 这条原则跟控制反转有点类似，主要用来指导框架层面的设计。高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细
  节，具体实现细节依赖抽象。

理论六：我为何说KISS、YAGNI原则看似简单，却经常被用错？

如何理解“KISS 原则”？
- 根据情况来看，不同情况 KISS 就不一样
- 如何写出满足 KISS 原则的代码？
  - 不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等。
  - 不要重复造轮子，要善于使用已经有的工具类库。经验证明，自己去实现这些类库，出
    bug 的概率会更高，维护的成本也比较高。
  - 不要过度优化。不要过度使用一些奇技淫巧（比如，位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性。
  - 评判代码是否简单，还有一个很有效的间接方法，那就是 code review。如果在 code review 的时候，同事对你的代码有很多疑问，那就说明你的代码有可能不够“简单”，需要优化啦。
YAGNI 跟 KISS 说的是一回事吗？
- YAGNI 原则跟 KISS 原则并非一回事儿。KISS 原则讲的是“如何做”的问题（尽量保持简单），而 YAGNI 原则说的是“要不要做”的问题（当前不需要的就不要做）。
- YAGNI 你不会需要它。
  它的意思是：不要去设计当前用不到的功能；不要去编写当前用不到的代码。实际上，这条原则的核心思想就是：不要做过度设计。
- 比如，我们的系统暂时只用 Redis 存储配置信息，以后可能会用到 ZooKeeper。根据
  YAGNI 原则，在未用到 ZooKeeper 之前，我们没必要提前编写这部分代码。当然，这并不是说我们就不需要考虑代码的扩展性。我们还是要预留好扩展点，等到需要的时候，再去实现 ZooKeeper 存储配置信息这部分代码。

理论七：重复的代码就一定违背DRY吗？如何提高代码的复用性？

DRY 原则
- 实现逻辑重复，但功能语义不重复的代码，并不违反 DRY 原则。实现逻辑不重复，但功能语义重
  复的代码，也算是违反 DRY 原则。除此之外，代码执行重复也算是违反 DRY 原则。

说白了违反这个原则两个条件：功能语义一样，实现逻辑也差不多就是重复了

代码复用性
- 减少代码耦合
- 模块化
- 业务与非业务逻辑分离
- 通用代码下沉
- 继承、多态、抽象、封装
- 应用模板等设计模式
- 满足单一职责原则
复用意识：在写代码的时候，我们要多去思考一下，这个部分代码是否可以抽取出来，作为一个独立的模块、类或者函数供多处使用。在设计每个模块、类、函数的时候，要像设计一个外部 API 那样，去思考它的复用性。

我们在第一次写代码的时候，如果当下没有复用的需求，而未来的复用需求也不是特别明确，并且开发可复用代码的成本比较高，那我们就不需要考虑代码的复用性。在之后开发新的功能的时候，发现可以复用之前写的这段代码，那我们就重构这段代码，让其变得更加可复用。

相比于代码的可复用性，DRY 原则适用性更强一些。我们可以不写可复用的代码，但一定不能写重复的代码。

理论八：如何用迪米特法则（LOD）实现“高内聚、松耦合”？

如何理解“高内聚、松耦合”？
- “高内聚、松耦合”是一个非常重要的设计思想，能够有效提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。
- 高内聚
  - 用来指导类本身的设计。就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一类中。相近的功能往往会被同时修改，放到同一个类中，修改会比较集中。
    说白了就是方便修改
  - 实现：单一职责原则是实现代码高内聚非常有效的设计原则。
- 松耦合
  - 用来指导类与类之间依赖关系的设计。在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动也不会或者很少导致依赖类的代码改动。（包括测试类）
  - 实现：依赖注入、接口隔离、基于接口而非实现编程都是为了实现代码的松耦合。
如何理解“迪米特法则”？
- 不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合，让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化，需要了解这一变化的类就会比较少。