構建器模式與依賴注入（例如通過Guice）

Question

我正在開發一個簡單的樹形結構數據庫，我通常通過Builder（Builder模式）設置依賴項或可選設置。 現在我不確定何時使用Guice，何時使用Builder模式以及何時使用靜態工廠方法而不是構造函數本身。 我已經多次閱讀過Effective Java，我認為它至少提到了不暴露構造函數的許多優點。 是時候重讀了;-)

那么，您是否知道明顯可區分的案例？ 我不應該暴露構造函數？ 因此，例如在每種情況下寫public static Foo getInstance(...) { return new Foo(...)} ？

Answer 1

我堅信你不需要為一切使用依賴注入。

• 對於LookupService ，自然會注入一個Dictionary ，使其實現可以通過配置進行交換。

• 另一方面，對於Firewall 。 它很自然地可以通過提供的Factory或Builder創建自己的FireWallRules 。

作為指導，注入您需要配置的內容 ，不要自動注入其他所有內容。

---

考慮一個static factory (*)

• 需要命名構造邏輯。 例如， Lists.newArrayList()
• 建築如此復雜，不屬於班級本身
• 不需要工廠配置，工廠沒有副作用

考慮instance factories

• 有復雜的實例化邏輯
• 需要配置工廠
• 使用AbstractFactory設計模式
• 需要在整個程序生命周期中創建其他對象

考慮一個builder

• 有復雜的參數選擇。 例如，5個參數，其中一些是可選的。

---

(*) 靜態方法並不總是可測試的，在我看來，一個人的存在總是有動力的 。 工廠的典型用例是減少耦合 。 通過使用static factory ，能力完全喪失。

Answer 2

構建器模式與依賴注入

這些2在您的腦海中甚至接近可比性如何？
當您需要處理構造函數具有大量參數（可能是可選的）的類時，將使用構建器模式 ，此模式使您的代碼更易於讀寫。

依賴注入是一種有助於松散耦合的方法，可以將更高級別類的依賴性移除到更低級別的類。 例如，需要連接到數據庫的類不會直接創建連接，而是“注入”連接，並且可以將此連接交換到其他數據庫，而不會影響使用它的代碼。

Answer 3

我已經開始在我的大部分項目中使用構建器，事實證明我可以用構建器和單例替換所有的DI。

即：

AppContext appContext = new AppContext.Builder()
.setProperties(testProps)
.setDB(testDB)
.build();

// run tests

沒有DI，我的代碼變得更加簡單。