有效的Java項目1適用於TDD和依賴注入

Question

我一直在閱讀Effective Java，我對第一個項目“使用靜態工廠方法而不是構造函數”與TDD和依賴注入有關。

該項目表示您應該避免使用public / protected / default構造函數並使用靜態工廠公開它。 我同意與使用靜態工廠相關的所有優點，例如工廠可以有名稱，你可以返回子類型，你可以減少冗長等等。但是，我認為缺點是Joshua錯過了TDD，因為你的代碼中有靜態工廠會導致緊耦合你不能用它來模擬這個類。 我們將無法模擬將擁有靜態工廠的類。 因此，它阻礙了測試驅動的開發。

第二點，我認為他錯過了在今天的企業開發中大多數應用程序使用一個或另一個依賴注入容器。 所以，當我們可以使用DI注入依賴項時，為什么要使用它呢？

請解釋它如何應用於今天的Java企業開發，包括DI和TDD。

Answer 1

DI引擎是工廠。

Joshua Bloch非常了解DI。 我認為這是歷史的一件神器，因為DI的上升是在第一版“Effective Java”之后出現的。

“Effective Java” 於2001年出版 。 Martin Fowler在2004年創造了這個詞.Spring的1.0發布於2004年3月。

約書亞布洛赫沒有修改第二版的那一章。

關鍵是“新”引入的耦合。 任何了解這一點的人和工廠都可以輕松實現對DI發動機的跨越。 關鍵是他關於“新”的陳述和使用工廠的補救措施仍然是正確的。

Answer 2

我在這里看到兩個不同的問題：

• 靜態工廠與使用new（）
• 依賴注入

使用new時，您的代碼與使用靜態方法緊密耦合，實際上甚至更糟，因為靜態工廠可以做一些魔術並返回一些特定的實現，只要它是接口的子類或實現。

依賴注入原則也被稱為好萊塢原則：“不要打電話給我們，我們會打電話給你”。 所以在那個philosphy中你不應該在你的代碼中調用new（）或靜態工廠，但是有一個外部的東西為你做，DI框架或單元測試。 這與工廠或新的使用無關，因為這是在其他地方完成的。

在這種情況下，工廠更好，因為您可以在您的控制下注入測試工廠。 對於new，這是不可能的（沒有對類路徑做奇怪的事情，比如在測試類路徑中隱藏帶有虛擬對象的實現，我不推薦btw）。

Answer 3

我有同樣的擔憂，這就是我找到你的問題的方式。

你說：

因為在你的代碼中有靜態工廠會導致緊耦合，你不能使用它來模擬類

本書建議您應該使用靜態方法（api設計）公開類的構造函數。 它並不表示您在整個應用程序中使用“硬編碼”靜態調用（api用法）。

假設你正在使用Guice for DI，你的界面叫做Connection ，你可以這樣做：

bind(Connection.class).toInstance(Connections.makeASpecificConnection(params));

然后是你常用的@Inject Connection connection;

當然，這是你的連接是單身人士。 如果不是，你可以為一個抽象工廠注入一個實現，該實現創建調用你的類的靜態方法的實例，但這可能是過度的，你最好單獨使用Guice。

請記住，本書的主要目標不是構建大型企業應用程序，盡管它仍然非常有用。 引用本書前言：

雖然本書不僅僅針對可重用組件的開發人員，但在過去二十年中我編寫此類組件的經驗不可避免地使用了這本書。 我自然會考慮導出的API（應用程序編程接口），我鼓勵你這樣做。