依赖注入的正确结构（使用 Guice）答案

【问题标题】：Proper structure for dependency injection (using Guice)依赖注入的正确结构（使用 Guice）
【发布时间】：2011-11-23 02:21:13
【问题描述】：

我想要一些建议和反馈，以了解如何为具有下述结构的系统构建依赖注入的最佳方式。我正在使用 Guice，因此更喜欢以基于注释的声明为中心的解决方案，而不是重 XML 的 Spring 样式配置。

考虑一组相似的对象Ball, Box, and Tube，每个都依赖于Logger，通过构造函数提供。（这可能并不重要，但所有四个类都恰好是应用程序的单例类，而不是四人组。）

ToyChest 类负责创建和管理三个形状对象。 ToyChest 本身不依赖于Logger，除了创建形状对象之外。

ToyChest 类被实例化为 Main 类中的应用程序单例。

我对在ToyChest 中构造形状的最佳方法感到困惑。我要么 (1) 需要访问已附加到 Module 绑定 Logger 到实现的 Guice Injector 实例，要么 (2) 需要创建一个新的 Injector 附加到右侧 Module。

(1) 是通过在ToyChest 中添加一个@Inject Injector injector 字段来完成的，但这感觉很奇怪，因为ToyChest 实际上并没有任何直接的依赖关系——只有它实例化的孩子的那些。

对于 (2)，我不确定如何传入适当的 Module。

我在正确的轨道上吗？有没有更好的方法来构建它？

question 的答案提到传递 Provider 而不是直接使用 Injector，但我不确定它应该如何工作。

编辑：

也许一个更简单的问题是：在使用 Guice 时，哪里是构造形状对象的合适位置？ ToyChest 会对它们进行一些配置，但我想它们可以在其他地方构建。 ToyChest（作为管理它们的容器），而不是 Main，在我看来只是构建它们的合适位置。

【问题讨论】：

Ball、Box 和 Tube 都是应用程序单例，但它们是由 ToyChest 创建的？你能澄清为什么需要这样吗？可以在玩具箱建成时将它们交给它吗？
1) ToyChest 决定创建哪些。 2) 它们可以通过构造函数传递给 ToyChest，但在其他任何地方都不需要它们。所以这会（在我看来）不必要地使构造函数复杂化。还有一个乌龟问题。是什么让它们传递给 ToyChest？也许通过构造函数传递它们是正确的方法，我只是没有看到更大的结构。

【解决方案1】：

正确的方法是让 guice 构建您的依赖项。那就是创建和配置。

在您的情况下，您应该在Main 中构建一个注入器。从注射器你得到ToyChest。当您通过注入器获取ToyChest 时，它由 guice 管理，您可以依赖它来提供正确配置的所有依赖项。

在您的情况下，您可以在ToyChest 中注入Provider<Ball>、Provider<Box> 等，并在需要时从提供程序中检索实例。 ToyChest 不负责构造实例，只是为了使用它。如果您有插件架构，也可以查看MapBinder。

到目前为止，一切都由 guice 管理，因此形状可以在 using 类不知道的情况下注入其记录器。

如果您有一些运行时参数想要传递给新创建的形状实例，您可以使用AssistedInject。

提示：你不需要使用构造函数注入，你可以在字段或setter上进行注入，这简化了构造函数。

【讨论】：

谢谢，这支持了我在提出问题后得出的结论，并建议了一些其他选择。 ToyChest 需要具有 DI 感知能力，要么通过构造函数/设置器接受形状，要么接受从中获取形状的工厂/提供者/映射绑定器。我认为我的问题在于颠覆了我的大部分控制权！