最近发现依赖注入我现在正试图掌握它的使用频率和距离.

例如,让我们说我有一个对话框,提示用户注册详细信息 – 名字,姓氏,电话号码,序列号 – 这类事情.应以各种方式验证数据(例如,名字和姓氏不为空,序列号是一定长度).验证后,它应缓存在本地计算机上,并发送到注册服务器.只有在所有这些事情成功或用户取消后,对话框才会关闭.

这可能是我们在这里尝试实现的四件事(责任)：UI,验证,本地缓存,将数据发送到非本地服务器.

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

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

但也许那没关系？在多年看到代码之类的东西之后,它确实对我来说有点陌生.但是我也可以看到这种情况如何迅速升级 – 如果还有其他各种小事需要做什么 – 注入了多少东西变得“太多”？

请不要尝试在示例场景中选择漏洞,我只是用它来说明.我对DI的原理更感兴趣,在什么时候你可能会把它放得太远.

最佳答案 嗯,你当然可以做到这一点.注入验证很有意义,因为您可以围绕验证代码编写单元测试,这些代码不需要激活任何GUI组件即可工作.注入缓存是有道理的,因为对话框不必知道有关其接口之外的缓存系统的任何信息.注入一个发送者很有意义,因为你的对话框不一定要有最模糊的想法.

我习惯把事情分得很重,因为我喜欢单一的责任原则,我喜欢编写尽可能纯粹的代码.

问题是当你注入太大的接口时,你不再有任何合理的想法,你注入的东西可能实际上需要调用那些接口的哪些接口,并且交互变得复杂,你的单元测试开始依赖于确切地说,依赖项已经完成了什么,因为当你知道75％的不使用它时,你不会费心去模拟整个界面.

因此,确实注入明显不同的职责,但要确保以适当的约束方式设计其接口.类可以同时实现多个接口,因此不像你不能将接口切成小块,而是根据需要使用相同的对象实现它们.从属代码永远不必知道！

至于当你把它拿得太远…很难说真的,但我不认为你到达那一点,直到你用一个没有添加任何东西的界面注入东西.我总是想注入有副作用的东西,因为这对单元测试和保持事情更合理是一个巨大的帮助.如果你可以将业务逻辑拆分成纯类并注入那些你将会有一个非常棒的时间为它编写单元测试,那么这可能是值得的.

我使用这样的测试：

>它是否进行I / O并且我还没有进入I / O提供类？注入它.
>它是否提供自包含的处理,我不需要知道细节？注入它.
>它是否做了一些不属于我的责任的事情？注入它.

你的旅费可能会改变.