kuanat
46 天前
我之前在关于 go 的一些帖子里提到过一个观点，因为 go 的依赖注入太普遍，也太简单了，所以 go 的依赖注入“框架”是非常不流行的。而 google/wire 也不是其他语言一般意义上的依赖注入框架，更准确地说它是自动生成初始化代码的框架，解决的是自动化的需求问题，而非解决注入依赖的问题。还有一个原因是，go 语言提倡显式控制流，所以类似 try...catch 的跳转机制，包括基于中心注册的注入依赖框架（通过运行时反射匹配），都不容易被 go 社区接受。
造成这种现象的更深层的原因，我认为在于 go 对于面向对象的抽象有两个重要的思想转变，一个是接口由需求方定义，另一个是用组合代替继承。前者就是所谓的 duck typing ，实现接口并不需要显式声明，后者是 struct embedding/receiver method ，两者结合，go 可以用极其简单的方式实现 mock 功能以及对第三方代码的复用。
作为对比，Java/C# 在设计思想上还停留在供给方定义接口的层面上，而需求方通常又不会主动 fork 修改供给方的代码，所以要“实现”一个接口，往往是通过所谓的适配器 Adapter 模式。相比于 struct embedding ，这种适配器模式尽管达到了在不修改第三方代码的前提下“实现”接口的目的，但它要求适配器要持有原始类的实例对象。
如果是 1:1 的接口转换，这种模式还勉强够用，如果是比较复杂的接口转换场景，receiver method 的优势就体现出来了，既可以对自定义的结构增加实例方法，也可以通过别名对第三方或者内置类型添加方法。C# 为此增加了 Extension Methods ，使得它能做到和 go 一样的效果。但是 Java 是没有办法在不修改代码的前提下，为已有类型添加方法的。
所以你会看到 Java 生态中，大部分的供应者在编写代码时，会首先编写接口，毕竟测试与 Mock 场景极其依赖接口。同时适配器模式不是复用数据结构，而是间接持有实例，所以会导致需要管理（相对于 go ）更多的对象实例。于是，很多大型项目会直接使用 mocking 框架来简化对于大量实例的管理。由此可以看出，go 多数时间是只需要管理自己编写的（或者封装的）实例的，这极大简化了开发者的心智负担，也减少了对使用工具管理实例的需求。
这种对于大量对象的管理需求，才是依赖注入框架的意义所在。对于实例的管理，除了初始化构造，还包括生命周期。现在无论让谁来设计一套通用的依赖注入框架，它对于对象实例本身的管理一定是全局的，也就有了所谓的 DI 容器，另一方面它对于对象实例声明周期的管理一定是隐式的，开发者可以声明 transient/scoped/singleton 之类的意图，但框架并不允许开发者自己手动管理。
回到 go 的生态来看，一方面既没有管理那么多对象实例的需求，另一方面也不提倡隐式控制流，加上 go 生态中显式传递 context 是事实上的标准，所以 DI 的存在空间就非常小了。如果非要在 go 中实现依赖注入，就好比手持锤子看什么都是钉子，解决一个不存在的问题。