java - 创建 10 个/100 个 Guice 注入(inject)器是否被认为是不好的实践/设计？

Question

考虑一个假设的应用:

• 需要创建数十甚至数百个小组对象
  • (A 组:A 类实例、D 类实例、M 类实例。属性 P')
  • (B 组:B 类实例、D 类实例)
  • (C 组:B 类实例、D 类实例、F 类实例。属性 P'')
• 这些对象中的每一个都是由其自己的 Provider 创建的，该 Provider 使用 MapBinder 或 MultiBinder(典型的“插件”用例)向父/根注入(inject)器注册。
• 为了创建每个组，将创建一个新的子注入(inject)器，该子注入(inject)器使用根中的提供程序以及该子注入(inject)器本地的一些其他提供程序 - 例如配置/属性绑定(bind)
• 这组紧密的对象被一起创建来执行某些任务，然后一起丢弃 - 几个小时后
• 该群组有一些独特的参数
  • 意思是，组内创建的每个对象都具有不同的配置属性
  • 它们与不同组中该类的另一个实例不同

问题:假设由于某种原因，上述问题无法通过使用工厂、构建器、创建者等常规设计模式来完成:

• 上述方法有什么问题吗？
  • 性能、内存占用
  • 可读性(与使用普通旧式 Java new 相比)
• 听起来是不是太复杂了，需要依赖库来做一些简单的事情？

Answer 1

在您描述的抽象级别上，这听起来像是一个合理的解决方案，并且有利于一些良好的设计模式(例如松散耦合和实例不变性)。据我所知，与满足这些复杂需求的任何类似解决方案相比，Guice 不会对内存泄漏或其他性能问题造成任何更大的威胁 - 只需留意您保留的引用，以便 GC 可以完成其工作。

对于这一点，如果您依赖于垃圾收集，那么在 Guice 中创建单例对象时您可能需要小心。只要 Injector 可访问，声明为 @Singleton(或 asEagerSingleton 或 toInstance)的对象就不能被垃圾回收，因为如果再次请求，Injector 必须返回完全相同的实例。在桌面虚拟机中，获取无状态对象的多个实例可能更便宜，这样 GC 就可以收集它们，而不是将对象声明为永远无法收集的单例。