dependency-injection - 依赖注入(inject)能走多远？

Question

最近发现了依赖注入(inject)，我现在正试图掌握使用它的频率和距离。

例如，假设我有一个对话框，提示用户输入他们的注册详细信息——名字、姓氏、电话号码、序列号——诸如此类。应以各种方式验证数据(例如，名字和姓氏不为空，序列号为一定长度)。一旦验证，它应该被缓存在本地机器上，并发送到注册服务器。只有在所有这些事情都成功或用户取消后，对话框才应该关闭。

所以这可能是我们在这里尝试实现的四件事(职责):UI、验证、本地缓存、将数据发送到非本地服务器。

对话的职责是什么，应该注入(inject)什么？ 显然对话框是 UI，但验证、缓存和数据发送都应该注入(inject)吗？我认为他们会这样做，否则对话框类必须知道数据字段背后的逻辑才能进行验证，它必须知道如何以及在何处缓存数据，以及如何将数据发送到某处。如果是这样，这可能会在调用者端导致一些大量代码(假设我们通过构造函数进行注入(inject)，我认为这比 setter 函数更可取)，例如

MyDialog dlg(new validator(), new cacher(), new sender());

但也许没关系？经过多年看到对话框之类的东西可以做所有事情的代码，它现在对我来说确实有点陌生。但我也可以看到这种情况如何迅速升级——如果它需要做各种各样的其他小事情怎么办——有多少被注入(inject)的东西变得“太多”了？

请不要试图在示例场景中挑洞，我只是用它来说明。我对 DI 的原理更感兴趣，在什么时候你可能会走得太远。

Answer 1

那么你当然可以做到这一点。注入(inject)验证很有意义，因为这样您就可以围绕验证代码编写单元测试，而无需启动任何 GUI 组件即可工作。注入(inject)缓存是有意义的，因为对话框不需要知道任何关于缓存系统超出其接口(interface)的信息。注入(inject)发件人很有意义，因为您的对话不必对任何事情的去向有最模糊的想法。

我有一个把事情分开的习惯，因为我喜欢单一责任原则，我喜欢编写尽可能纯粹的代码。

问题是当您注入(inject)太大的接口(interface)时，您不再有任何合理的想法，您注入(inject)的东西可能实际上需要调用这些接口(interface)的哪些位，并且交互变得复杂并且您的单元测试开始依赖正是依赖关系完成了什么，因为当您知道 75% 的界面不会被使用时，您不会费心去模拟整个界面。

因此，请务必注入(inject)明显是独立职责的东西，但请确保以适当约束的方式设计它们的接口(interface)。类可以同时实现多个接口(interface)，所以并不是说你不能把接口(interface)分割成小块，而是如果你愿意的话，可以用同一个对象来实现它们。依赖代码永远不必知道!

至于你什么时候走得太远......真的很难说，但我认为你直到你使用一个完全没有添加任何东西的接口(interface)注入(inject)一些东西时才会达到这一点。我总是想注入(inject)有副作用的东西，因为这对单元测试和保持更合理有很大帮助。如果您可以将业务逻辑拆分为纯类并注入(inject)它们，那么您将有一段很棒的时间为它编写单元测试，所以这可能是值得的。

我使用这样的测试:

它做 I/O 并且我还没有在 I/O 提供类中吗？注入(inject)它。

它是否提供了我不需要知道细节的独立处理？注入(inject)它。

它会做一些不属于我的单一职责的事情吗？注入(inject)它。

你的旅费可能会改变。