靜態工廠和依賴注入

Question

在Effective Java（書籍）中，建議使用靜態工廠。

另一方面，建議保持依賴關系明確，例如使用DI。

但是當我想使用靜態工廠時，將跳過此顯式性，因為將通過調用靜態工廠方法來接收對象實例。 使用靜態工廠方法，我不必傳入包含靜態工廠的對象。

這兩件事怎么結合在一起呢？

Answer 1

真好問題。
靜態工廠確實存在這個缺點（其中包括）：它們不是顯式的，因此它們不能用作可切換的依賴項。

我不認為你可以讓這兩件事一起工作，因為靜態方法與類相關聯，而依賴注入與實例相關聯。
所以它是一種設計選擇。

就個人而言，我使用工廠方法，因為我不想允許顯式設置工廠返回的依賴項。
在這種情況下，您希望掌握對象創建：一致性，緩存等......並且您希望提供一個清晰的API。 這是一種非常直接的方式來保證這一點。
設置具有依賴注入的對象不會提供。

一般來說，我是為那些我不希望既不提供替代實現也不想在單元測試期間進行模擬的類做的。
我希望掌握創建的業務/模型類以及一些“實用程序”類的情況。
但是一旦需要顯式設置依賴關系，我就會將靜態工廠重構為允許顯式設置依賴關系的東西。
如果始終需要創建對象的主體，我將靜態工廠轉換為我注入的實例工廠。
否則我直接注入工廠返回的對象。

Answer 2

這個問題有兩個方面：

1. 正在創建的對象。
2. 正在進行創建的對象。

工廠，構造函數和自動解析容器是改變對象創建方式的手段（問題2）。 這與對象允許自己創建的方式完全不同（問題1）。

作為一般啟發式：

1. 正在創建的對象在構造方式方面應該盡可能靈活，並且應該在其構造函數中明確地宣傳它們的所有依賴項（即使構造函數是私有的，創建者也使用工廠）。

2. 創建者應該與他們創建的對象分離，因為應用程序需要保持其靈活性。 高度穩定的依賴關系可以直接依賴。 可能會改變或被替換的依賴性不應該

靜態工廠，實例工廠，構造函數和容器自動解析之間的差異主要只是語法。 最大的區別是語義表達（它與開發人員就程序結構進行通信）以及在運行時解析不同實現的能力。

要回答你的核心問題，這兩件事可以結合在一起，因為它們是分離問題的一半的解決方案。 你可以一起使用它們。