Getter DI是个好主意吗？

有时，您可能会听说通过getter方法完成的依赖项注入，该方法会覆盖子类或伪造测试框架。它允许类具有一组设置的依赖关系，该依赖关系实际上是经过硬编码的，但是可以根据需要“注入”。

从现在开始，我已经写过关于所谓的“公司编码”依赖项的想法。不过，我在那篇文章中没有提到吸气剂注入，因为当时我还不太了解，现在我认为这并不是一个好主意。我对第一个想出这种回旋方式做DI的人表示敬意，但这并不意味着我喜欢它。我已经做了一些练习来弄出round回的做事方式，但这并不意味着我没有意识到这是一个坏主意。

我不能说我的观点应该是关于吸气剂注入是否不良以及永远不应该被触及的最终裁决。我只想说说我对此有什么反对，并讨论更好的选择。

什么是吸气剂注入？

吸气剂注入是指您使用吸气剂方法进行硬编码的“依赖注入”。我使用引号是因为，因为它是硬编码的，所以它不是真正的依赖注入。 “注入”依赖项的方式是通过子类化和覆盖getter方法或通过使用反射（通常是使用模拟库）替换它来更改getter。我将举一个继承的例子。

public class ClassUnderTest
{public void saySomething(){System.out.println(getString());}protected String getString(){return "Hello World";}
}public class GetFrench extends ClassUnderTest
{@Override protected String getString(){return "Bonjour le monde";}
}

为什么吸气剂注射不好？

我有什么反对吸气剂注入的方法？简而言之，我不喜欢它的最大原因是因为您的操作方式。必须对要测试的内容进行子类化或模拟并不是一个好主意，因为这样做可以使您不再测试相同的类。您正在测试其他内容。

我不喜欢的另一个原因是因为人们可能很难理解。测试代码必须易于读取和编写，并且使用getter注入会在测试代码中造成混淆。

我该如何解决？

上面的链接文章对如何进行“公司编码”依赖项进行了完整描述，但是我将在此处进行快速概述。

您需要做的第一件事是提供一种设置字段以保存依赖项的方法。最好的方法是通过构造函数（如果您当前具有公共构造函数，则应使用程序包私有的构造函数重载），因为它有助于设计不可变的类。第二种选择是提供使用该依赖项的方法的程序包私有重载，其中重载具有一个附加参数来获取依赖项。这种技术也非常适合不可变的设计。否则，您可以使用package-private字段或setter来设置依赖关系。

下一步是确定依赖项是普通对象还是工厂。如果旧的getter每次都产生一个新对象， 并且需要 ，则该依赖关系应该是工厂。

如果您想要更深入的解释，请查看我的旧文章。