工廠模式理解

工廠模式是一種創新的設計模式，其目的是提供一個接口，用于創建相關或相關對象的族，而無需指定其具體類。 創建邏輯封裝在工廠中，該工廠提供創建邏輯的方法或將對象的創建委托給子類。 客戶端不知道接口或類的不同實現。 客戶端只需要知道工廠即可用于獲取接口實現之一的實例。 客戶端與對象的創建是分離的。

通常，工廠模式以單例或靜態類的形式實現，因為只需要一個工廠實例。 這樣集中了對象的創建。

CDI框架

在Java EE中，我們可以利用CDI框架來創建對象，而無需了解對象創建的詳細信息。 這種脫鉤是Java EE實現控制反轉的方式的結果。 傳達的最重要的好處是將較高級別的類別與較低級別的類別分離。 這種解耦使具體類的實現可以更改而不會影響客戶端：減少耦合并提高靈活性。

CDI框架本身是工廠模式的實現。 容器在應用程序啟動期間創建合格對象，并將其注入到與注入標準匹配的任何注入點中。 客戶端不需要知道關于對象的具體實現的任何信息，甚至客戶端都不知道具體類的名稱。

public class CoffeeMachine implements DrinksMachine {// Implementation code}

像這樣使用它：

@InjectDrinksMachine drinksMachine;

在這里，容器創建了CoffeeMachine具體類的實例，根據其接口DrinksMachine進行選擇，并在容器找到合格注入點的任何位置進行注入。 這是使用工廠模式的CDI實現的最簡單方法。 但是，它不是最靈活的。

消歧

如果我們有多個DrinksMachine接口的具體實現， 將會發生什么？

public class CoffeeMachine implements DrinksMachine {// Implementation code} public class SoftDrinksMachine implements DrinksMachine {// Implementation code}

應該注入哪種實現？ SoftDrinksMachine或CoffeeMachine ？

@InjectDrinksMachine drinksMachine;

容器不知道，因此部署將因“模棱兩可的依賴項”錯誤而失敗。

資格賽

那么容器如何區分具體的實現？ Java EE為我們提供了一個新工具：限定符。 限定詞是自定義注釋，用于標記具體的類以及容器要注入對象的位置。

回到我們的Drinks機器以及兩個相同類型的CoffeeMachine和SoftDrinksMachine的具體類，我們將通過使用兩個限定符來區分它們：

@Qualifier@Retention(RetentionPolicy.RUNTIME)@Target({ElementType.METHOD, ElementType.FIELD})public @interface SoftDrink@Qualifier@Retention(RetentionPolicy.RUNTIME)@Target({ElementType.METHOD, ElementType.FIELD})public @interface Coffee

我們創建一個限定符名稱SoftDrink 。 這將注釋SoftDrinksMachine混凝土類，而Coffee將注釋CoffeeMachine類。

@Target注釋限制了我們可以在哪里使用這些限定符標記注入點，在這種情況下，是在方法和字段注入點上。 具有保留策略RUNTIME的注釋可確保注釋在運行時可用于JVM。

Target的可能值為：TYPE，METHOD，FIELD，PARAMETER。

正確標注了DrinksMachine接口的兩個具體實現。 CoffeeMachine類的注釋為@Coffee，而SoftDrinksMachine類的注釋為@SoftDrink 。

@Coffeepublic class CoffeeMachine implements DrinksMachine {// Implementation code}@SoftDrinkpublic class SoftDrinksMachine implements DrinksMachine {// Implementation code}

現在，您注釋注入點。 使用限定符@SoftDrink表示要在容器中注入SoftDrinksMachine類的位置，并使用限定符@Coffee來在容器中注入CoffeeDrinkMachine的位置 。 現在，我們已經向容器明確了應該在哪里注入我們的具體實現，并且部署將成功。

@Inject @SoftDrinkDrinksMachine softDrinksMachine;@Inject @CoffeeDrinksMachine coffeeDrinksMachine;

我們已經了解了Java EE的CDI框架如何實現工廠模式，如何隱藏對象的具體實現并允許創建與使用分離。 我們已經看到了如何使用限定符來選擇所需的實現，而無需了解有關對象創建的任何知識。

重要的是要記住，CDI框架只會實例化滿足托管Bean規范JSR 299的所有條件的POJO。但是，如果您要注入的對象沒有，那意味著我們不能利用CDI怎么辦？框架針對不符合要求的類的注入功能。 不，不是。 Java EE為我們提供了一個解決方案。 讓我們更深入地研究一下如何使用CDI框架將ANY類型的ANY類注入到注入點中。

生產者方法

Java EE具有稱為生產者方法的功能。 這些方法提供了一種實例化方式，因此可用于不符合托管bean規范的注入對象，例如需要使用構造函數參數進行正確實例化的對象。 其值可能會在運行時更改的對象以及其創建需要進行一些自定義初始化的對象，也可以通過生產者方法準備好進行注入。

讓我們看一個生產者方法，該方法產生一個用Books對象填充的List。

@Produces@Librarypublic List<Book> getLibrary(){// Generate a List of books called 'library'return library;}

Book對象列表將被注入到注解點@Library中。

像這樣使用它：

@Inject @LibraryList<Books> library;

生產者方法的一個重要特征是它的范圍。 這將確定何時調用該方法以及該方法產生的對象將保留多長時間。

默認情況下，生產者方法范圍是@DependentScoped 。 這意味著它將繼承其客戶范圍。

我們可以通過擴大范圍來進一步擴展此示例。 如果我們對生產者方法@RequestScoped進行注釋，則它將對其參與的每個HTTP請求僅調用一次，并持續到請求的持續時間。

@RequestScoped@Produces@Librarypublic List<Book> getLibrary(){// Generate a List of books called 'library'return library;}

可能的范圍是：

• RequestScoped – HTTP請求范圍
• SessionScoped – HTTP會話范圍
• ApplicationScoped –在用戶之間共享
• ConversationScoped –與JSF的交互
• DependentScoped –默認，從客戶端繼承

優點：易于實現，沒有樣板代碼，神奇地工作，任何對象都可以注入，按類自動配置

錯誤：命名注釋類型不安全

和丑陋：隱藏對象創建，難以遵循執行流程，IDE應該有所幫助

翻譯自: https://www.javacodegeeks.com/2015/12/factory-pattern.html

工廠模式理解

總結

以上是生活随笔為你收集整理的工厂模式理解_工厂模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。