《Dependency Injection Principles, Practices, and Patterns》中的经验教训

Source: Dev.to

Introduction

我作为软件开发者的第一份工作是为一家与微软关系非常密切的软件开发公司编写 C#。作为一名初级工程师，我对面向对象编程和 SOLID 原则有基本的概念，但每次打开使用 .NET 依赖注入容器的项目时，我都会感到困惑。为什么要为所有东西都写接口？为什么不在类内部直接实例化对象？为什么所有实例都要通过构造函数传递？这看起来非常官僚。我不明白为什么要遵循这些增加大量代码的严格规则，而我们完全可以通过去掉那些模板化的接口、在需要的地方直接实例化类来让代码保持简洁。

快进几年的时间，在另一家公司工作时，我决定阅读 Dependency Injection Principles, Practices, and Patterns。我记得这本书出现在一位 YouTuber（Christopher Okhravi）视频的背景中。当时，我认为阅读它可以帮助我为项目引入更多结构和秩序。读完后，我可以说它回答了我所有的问题，甚至更多。它帮助我对面向对象编程和软件设计有了更深入的理解。

作者 Steven van Deursen 和 Mark Seemann 对依赖注入的核心概念——解耦、内聚以及它们与 SOLID 原则的关系，解释得非常到位。他们提供了依赖注入模式的示例、常见的反模式和代码异味，这些都阐明了依赖注入的主要优势。全书写得很出色，我强烈推荐给所有从事面向对象编程的人。

下面列出书中对我软件开发方法影响最大的三个观点。这并不是完整的摘要；若想全面了解依赖注入，建议阅读原书。

Low Coupling

本书用酒店吹风机的类比来介绍耦合的概念。许多酒店的吹风机是直接硬接在插座上的。像高度耦合的代码一样，维修或更换时非常麻烦。当吹风机坏了，电工必须先关闭房间的电源并拆除电线才能更换吹风机。对于高度耦合的代码，你往往必须先修改其他模块，才能替换需要修复或重构的模块。

相反，带插头的吹风机更容易更换；只需把它从墙壁插座拔下即可。松散耦合的软件也表现相同——更容易替换、移除和维护。

可维护性是软件开发的关键方面。一个不可维护的解决方案更改成本极高，这意味着业务的功能发布会变少。松散耦合的代码提升了项目的可维护性，使得新功能的开发更快。

High Cohesion

作者讨论了 SOLID 原则，特别强调 单一职责原则（SRP）：

单一职责原则指出，每个类应该只有一个导致其变化的原因。

在 SRP 的语境下，作者将 内聚 定义为类或模块中元素的功能相关性。相关性低意味着内聚度低，这会增加类违反 SRP 的可能性。

在追求松散耦合代码时，SRP 成为一条宝贵的指导原则。松散耦合应发生在具有高度内聚的模块之间；否则，软件将难以理解，可维护性也会受损。

Volatile and Stable Dependencies

虽然松散耦合的代码有助于提升代码库的可维护性，但它也有代价：代码中会出现更多的 接缝（seam）。

每当你针对抽象而不是具体类型编程时，就引入了一个接缝。接缝是将应用程序的各个组成部分组装在一起的地方，类似于服装的缝合点。

正因为有这笔代价，只有在必要时才应引入接缝，例如针对 易变依赖。易变依赖（相对于稳定依赖）满足以下任意条件：

• 它运行在不同的环境中（例如不同的机器或进程）。一个例子是数据库。
• 它尚未存在或仍在开发中。
• 它包含非确定性行为。
• 新版本可能包含破坏性更改。

Conclusion

还有许多我从本书中学到但未在此提及的概念。得益于其结构、解释和类比，这本书读起来轻松。我建议大家购买一本，至少阅读一次，并把它放在书架上，以备在遇到问题时随时查阅。