什么時候使用工廠而不是簡單地返回bean是一個糟糕的設計選擇？

Question

我們的應用程序大量使用工廠來吐出對象，但是我經常想知道它們是否真的一直很必要，並且將“已知對象”的實例創建為Bean不會更好。 論據是開發人員經常定制這些返回對象的實現（這些返回對象以其接口類型返回），並且由於我們在技術上並不“確切地”知道所得到的，因此最好使用工廠。 我現在要創建一個工廠，這需要接口，類實現以及工廠。 雖然我的對象不會改變-它實際上是具有特定目的的具體對象...我不應該僅實例化獲取並設置狀態的Bean嗎？ 我試圖避免過早的概括。

Answer 1

工廠或依賴項注入解決方案的全部目的是減少客戶端與對象的運行時類型之間的耦合。 確實，客戶端必須知道接口和數據源，但是現在，源可以自由返回實現接口的任何類型。 它還使您可以將運行時類型的知識封裝在一個地方-只有工廠或依賴項注入解決方案才需要知道。

這在生成運行時代理以實現聲明性事務時很有用。 從客戶的角度來看，他們正在處理接口。 工廠可以生成管理客戶端事務的代理。

鍵入“ new”后，客戶端將在運行時使用編譯類型。 更改它意味着更改客戶端。 如果您在代碼中有很多地方稱為“ new”，那么這可能是維護問題。

什么時候叫“新”？ 我認為在方法內部實例化在超出范圍時將被GC引用的本地對象是合適的。 該方法創建它們，使用它們，然后完成它們。 我不會在那里使用工廠或DI解決方案。

也許您應該關閉工廠並考慮使用依賴注入解決方案，例如Spring，Guice或PicoContainer。

Answer 2

擁有工廠方法意味着（但不總是意味着）該對象沒有公共默認構造函數。 這個想法是，如果有一個工廠方法（例如），您就不能繞過它並直接創建一個方法。

在最簡單的情況下，幾乎沒有理由擁有公共構造函數，而不是擁有返回新對象的公共靜態方法，並且該對象僅具有私有/受保護的構造函數。

話雖這么說，在某些情況下，您要么需要使用公共默認構造函數，要么很不方便。 示例包括使用Spring的BeanWrapper。 某些方法需要默認構造函數。 使用JavaBeans接口需要它。 沒有它，反射可能會很尷尬（這是前兩個原因的一部分），依此類推。

在這些情況下，除非工廠返回接口並且該類實現該接口，否則擁有工廠的價值可能很小。 再說一遍，也可以說大多數（如果不是全部）返回類型（和參數類型）應該是接口，無論如何不是類，而是一個完整的參數。

擁有工廠的另一個潛在缺點是，由於工廠可能會依賴或修改某種形式的外部狀態，因此會降低可測試性。 不一定是這種情況，但是例如以下代碼：

Calendar cal = Calendar.getInstance();

與

Calendar cal = new GregorianCalendar();

根據本地化/國際化會有不同的結果。