創建10s / 100s的Guice注射器是否被認為是不好的做法/設計？

Question

考慮一個假設的應用程序：

• 需要創建數十甚至數百個小型對象組
  • （組A：A類實例，D類實例，M類實例。屬性P'）
  • （B組：B類實例，D類實例）
  • （組C：B類實例，D類實例，F類實例。屬性P''）
• 這些對象均由自己的提供者創建，並使用MapBinder或MultiBinder在父/根Injector中注冊（典型的“插件”用例）
• 要創建每個組，將創建一個新的子注入器，該子注入器使用根中的提供程序以及該子注入器本地的其他一些提供程序（例如配置/屬性綁定）
• 緊密創建一組對象以執行某些任務，然后一起丟棄-幾個小時后
• 該組具有一些獨特的參數
  • 意思是，組內創建的每個對象都具有不同的配置屬性
  • 它們不同於該類在另一個組中的另一個實例

問題：假設由於某種原因，無法通過使用工廠，構建器，創建者等工廠設計模式來解決上述問題：

• 上述方法有什么問題嗎？
  • 性能，內存占用量
  • 可讀性（與使用普通的舊Java new ）
• 聽起來太復雜了，依靠庫來做一些簡單的事情嗎？

Answer 1

在您描述的抽象級別上，這聽起來像是一個合理的解決方案，並且有助於某些良好的設計模式（例如，松散耦合和實例不變性）。 據我所知，Guice不會比針對那些復雜需求的任何同類解決方案帶來更大的內存泄漏或其他性能問題的威脅-只需留意所保留的引用，GC就可以完成工作。

到那時，如果您依賴於對對象進行垃圾收集，則可能要在Guice中創建單例對象時要小心。 聲明為對象@Singleton （或asEagerSingleton或toInstance ）不能作為垃圾回收，只要注射器可達，因為注射器有義務返回完全相同的情況下，如果它是不斷詢問一次。 在台式機VM中，獲取無狀態對象的多個實例可能會比較便宜，以便GC可以收集所有實例，而不是將對象聲明為永遠無法收集的單個實例。