設計模式(四):從“兵工廠”中探索簡單工廠、工廠方法和抽象工廠模式

来源:http://www.cnblogs.com/ludashi/archive/2016/04/20/5379585.html
-Advertisement-
Play Games

前面陸陸續續的更新了三篇關於設計模式的博客,是關於“策略模式”、“觀察者模式”、“裝飾者模式”的,今天這篇博客就從“兵工廠”中來探索一下“工廠模式”(Factory Pattern)。“工廠模式”又可以分為“簡單工廠模式”(Simple Factory Pattern)、“工廠方法模式”(Facto ...


前面陸陸續續的更新了三篇關於設計模式的博客,是關於“策略模式”、“觀察者模式”、“裝飾者模式”的,今天這篇博客就從“兵工廠”中來探索一下“工廠模式”(Factory Pattern)。“工廠模式”又可以分為“簡單工廠模式”(Simple Factory Pattern)“工廠方法模式”(Factory Method Pattern)“抽象工廠模式”(Abstract Factory Pattern)。今天這篇博客就從頭到尾的來介紹一下這三種模式,並且給出相應的Swift代碼的實現。在文章的最後會給出“工廠方法模式”和“抽象工廠模式”的使用場景,併在一個示例中將兩者結合起來使用。同樣,博客最後仍然會給出示例在github上的分享鏈接。

工廠模式,顧名思義,肯定和工廠有關的模式。在現實生活中,我們都知道工廠是賦值生成產品的,也就是說工廠往外輸出不同的產品,這些產品可以是同一類型,也可以是不同的類型。在我們設計模式中的工廠也是用來生產產品的,不過此產品非比產品。工廠模式中的工廠負責生產“對象”,該工廠也就是對象的工廠。我們在使用工廠模式時,需要使用哪種類型的對象,我們就告訴“工廠”,工廠就會根據我們的指令來生產出相應類型的對象。

工廠模式的應用場景大部分是當你根據不同類型來生成不同對象時,就可以使用工廠模式來解決。也就是說將創建對象的過程封裝到工廠中來完成。接下來我們將會通過兵工廠造武器的例子來好好的聊一下工廠模式。這個兵工廠的示例我們先不使用工廠模式來實現出來,然後在通過“簡單工廠”、“工廠方法”以及“抽象工廠”模式來實現出來。當然下方我們還會用到“裝飾者模式”,關於裝飾者模式的詳情請參見《“花瓶+鮮花”中的裝飾模式(Decorator Pattern)》。廢話少說,進入今天的主題。

 

一、創建無"兵工廠"的武器庫

這一部分我們先給出不使用任何類型的“工廠模式”來實現我們的武器庫。該示例與之前我們介紹《“穿越火線”中的“策略模式”(Strategy Pattern)》使用的示例是一直的,不過之前我們側重於“策略模式”,而如今我們註重於“工廠模式”。當然這兩者可以共存,不過今天我們的重點是“工廠模式”,所以就不對“策略模式”進行討論了。下方是我們將要實現示例的類圖。

從下方的類圖不難看出,WeaponType是武器類型的介面(協議),其中有一個必須實現的方法就是fire()方法。AK、AWP、HK都實現了WeaponType協議。WeaponUser則是武器的使用者,WeaponUser與WeaponType當然是依賴關係。下方就是沒有使用“工廠方法”的類圖。

     

從上面的類圖來看,實現我們的代碼是並不困難的。下方就是WeaponType協議與武器AK、AWP、HK的具體實現。在每種武器實現時都有一個fire()方法,每種武器的fire()都有其獨特之處。

    

 

 

實現完各種武器後,我們得創建一個武器的使用者WeaponUser。武器的使用者根據武器的類型來使用武器。下方是武器的使用者WeaponUser、武器枚舉WeaponTypeEnumeration、測試用例以及輸出結果的截圖。WeaponUser中的fireWithType()方法就是根據不同的武器類型來創建不同的武器對象然後在調用武器的fire()方法。下方WeaponUser是直接對武器進行的創建,未用到工廠模式。

   

  

二、“簡單工廠”(Simple Factory)

由易到難,緊接著我們要使用“簡單工廠”模式對上述進行重寫。那麼我們為什麼要使用“簡單工廠”模式進行重寫呢?因為在之前我們“重構”的系列博客中也不止一次的提到過,要將變化的部分與不變的部分進行分離,對變化進行封裝。在上面的示例中,WeaponUser中的Swift-Case語句不難看出,隨著武器種類的增加或者減少,這個Switch語句就會隨之改變,後期會對此進行修改,可是WeaponUser中的其他部分是不變的。

本著將變化進行封裝的原則,我們將上面的Switch語句進行封裝,將其放到一個新的類中,在我們的WeaponUser中使用這個新封裝的類來創建不同的武器。對上述示例變化的內容提取封裝,於是就是形成了我們的“簡單工廠模式”。這個新提取被封裝的新的創建武器的類就是我們的工廠類,其職責就是用來創建各種各樣的武器,這個簡單工廠就是我們的“兵工廠”。下方就是我們“簡單工廠”的類圖,與第一部分的類圖相比,不難發現在WeaponUser與WeaponType之間多了一個WeaponFactory,這個WeaponFactory就是我們的簡單工廠。類圖如下:

    

有上面的“類圖”可以給出其代碼實現。當然下方的代碼是對上述示例中的WeaponUser類的重構。下方這個簡單的兵工廠類WeaponFactory就是我們封裝的簡單工廠。其中有一個方法專門負責使用武器類型來創建武器對象,這也符合“單一職責”的原則。該方法比較簡單,在此就不做過多的贅述了。下方的兵工廠類就負責生產武器對象,具體實現如下所示:

   

 

實現完我們的簡單工廠後,緊接著要修改我們的WeaponUser類。WeaponUser類依賴於上面的WeaponFactory工廠類,因為WeaponUser要使用WeaponFactory來創建不同的武器對象。WeaponUser類在使用了“簡單工廠”後的代碼如下,以及測試用例和輸出結果如下所示:

   

 

三、“工廠方法模式”(Factory Method Pattern)

第二部分的“簡單工廠”模式確實簡單,緊接著隨著需求的變更,我們需要為上述功能添加新的需求。武器不僅僅有種類,還有生產廠家,我們要為武器添加生產廠家。比如美國造AK, 德國造AK。則我們的用戶可以分為美國武器使用者(AmericaWeaponUser),德國武器使用者(GermanyWeaponUser)。在這種情況下,“簡單工廠”模式已不再使用。所以我們要使用即將出場的“工廠方法模式”(Factory Method Pattern)和“策略模式”(Strategy Pattern)對上述示例進行擴充。

在對示例進行擴充之前呢,我們先看一下“工廠方法模式”的定義,其中使用到了依賴倒置原則,也就是要依賴抽象而不依賴具體類。這一點與“面相介面編程而不面相實現編程有些類似”,下方是工廠方法模式的定義。

工廠方法模式:定義了一個創建對象的介面,但由子類決定要實例化的類是哪一個。工廠方法讓類把實例化推遲到子類。

 

1.“工廠方法模式”的類圖

如果你看完定義後,感覺抽象,那麼沒關係,看完下方的示例在看上述定義就會一目瞭然。下方就是我們要實現的“工廠方法模式”的類圖,也是在上面類圖的基礎上進行擴充的。下方“類圖”中不僅僅至於“工廠方法模式”的部分,還有我們之前介紹過的裝飾者模式。為了給武器添加生產廠商,我添加了“GermanyDecorator”德國造裝飾器和“AmericaDecorator”美國造裝飾器,下方圖中的紅框部分就是我們為武器添加的裝飾者,關於裝飾者模式的詳情請參見《花瓶+鮮花”中的裝飾模式(Decorator Pattern)》。

下方“類圖”中綠框中是我們該部分的主題,也就是我們“工廠方法模式”的核心。由下方類圖不難看出,與我們上面的“簡單工廠模式”類比的話,下方的“工廠方法模式”是沒有一個獨立的的工廠的類的,但是他有一些工廠方法。這些工廠方法的實現位於WeaponUser的子類中,由子類來確定生產出什麼種類的武器。這也就是上面工廠方法模式定義中所說的“將對象的實例化推遲到子類中”。“工廠方法模式”重點在於方法,利用繼承關係,以及子類間的差異化類創建不同的武器類型。AmericaWeaponUser(美國武器使用者)的createWeaponWithType()工廠方法就會創建美國造武器(為武器添加上“美國造”裝飾),同理GermanyWeaponUser(德國武器使用者)的createWeaponWithType()工廠方法就會創建德國造武器(為武器添加上“德國造”裝飾),這就是“工廠方法模式”的核心。有一點需要註意,同一個工廠方法中生產的是同一系列的不同產品,比如美國造的各種武器,這一點與抽象工廠不同。稍後在介紹“抽象工廠模式”時會給出對比。

   

 

2. 為“武器”添加裝飾者(代碼實現)

首先了我們為武器添加裝飾者,也就是上方類圖中紅框部分的“裝飾者模式”的代碼實現。還是那句話,因為“裝飾者模式”在之前的博客中已經進行了詳細的介紹,今天就不詳述了,直接給出其代碼實現吧。下方的代碼片段就是武器的兩個裝飾者,如下:

     

 

3.武器用戶介面的代碼實現

下方截圖中是武器用戶介面WeaponUser的實現,介面中聲明瞭一個賦值開火(fireWithType())的方法,和一個“工廠方法”(createWeaponWithType())。在WeaponUser中我們緊接著給出了fireWithType()方法的預設實現,在fireWithType()方法中調用了相應的“工廠方法”來獲取相應的武器類型,具體實現如下。

   

 

4.“工廠方法”的具體實現

當然在“工廠方法”模式中,工廠方法的具體實現我們是推遲到相應的子類中來完成的。在該示例中就是在GermanyWeaponUser和AmericanWeaponUser中來實現具體的工廠方法。在GermanyWeaponUser(德國武器使用者)中的工廠方法給不同種類的武器添加上了“德國造”裝飾器,同樣在AmericanWeaponUser中的工廠方法中也做了類似的事情。具體代碼如下所示:

   

 

5.測試用例

上面就是我們的全部代碼了,接下來就到了我們測試的時候了,下方截圖就是我們的測試用例以及輸出結果。因測試用例比較簡單,在此就不做過多贅述了,一句話:德國用戶使用德國造,美國用戶使用美國造。

    

 

四、“抽象工廠模式”(Abstract Factory Pattern)

上面我們使用到了“工廠方法模式”以及“裝飾者模式”,接下來我們要做的事情就是將上面的“工廠方法模式”改為“抽象工廠模式”(Abstract Factory Pattern)。我們在改的過程中,不會動“工廠方法”一以外的部分,我們只重寫第三部分中類圖的綠框部分。簡單的說,就是將上面的“工廠方法模式”替換為“抽象方法模式”,然後在對比兩者的異同。當然本部分是“抽象工廠” + “裝飾者”,而上一部分是“工廠方法” + “裝飾者”

下方是“抽象工廠的定義”

抽象工廠:提供一個介面,用於創建相關或依賴對象的家族,而不需要明確指定具體類。

 

1.設計“類圖”

定義一般是不太好理解的。言歸正傳,還是老套路,先來看一下我們將要實現的類圖是怎樣的。該部分的“類圖”與第三部分的類圖非常相似,因為是在第三部分的類圖上修改的。下方“類圖”中紅框的部分是我們未修改的部分,與第三部分中的類圖一致。而綠框中則是我們使用“抽象工廠模式”重寫後的結果。“抽象工廠”顧名思義,就是抽象了的工廠,這個抽象你可以使用介面、協議、抽象類來實現。

下方綠框中的WeaponFactoryType協議就是我們的“抽象工廠”,而AmericanWeaponFactory,GermanyWeaponFactory是其不同種類的具體實現。WeaponUser就是武器使用者,對於WeaponUser來說,它是依賴於介面,而不依賴於具體實現的,這也是設計模式的一大準則。有下方的“類圖”不難看出,“抽象工廠”是一些特定工廠的集合,也就是組合的關係。具體的工廠中生產的同一品牌的不同產品。而“工廠方法”就與此不同了,“工廠方法”就是這一系列產品的具體實現。下一部分我們會在下方“抽象工廠”基礎上添加上“工廠方法模式”,下方會給出具體實現,本部分還是主要瞭解“抽象工廠模式”。

   

 

2. 代碼實現

 有了類圖了,我們再去實現我們的代碼就容易多了。我們只需要在第三部分的基礎上將“工廠方法”替換為抽象工廠即可。下方代碼就是“抽象兵工廠”、“美國兵工廠”、“德國兵工廠”的實現代碼。在“美國兵工廠”中使用了AmericaDecorator裝飾器,在“德國兵工廠”中使用了GermanyDecorator裝飾器。每個“兵工廠”都創造了其獨居特色的武器裝備。

    

 

實現完工廠後,我們要修改武器的使用用戶。因為在“工廠方法”模式中,不同工廠武器的選擇是在用戶的子類中實現的,而在“抽象工廠”中就使用不到子類了。“抽象工廠”模式的用戶與“簡單工廠”模式的用戶非常相似。下方就是我們“抽象工廠”的用戶,其依賴於“抽象工廠”介面,具體實現如下所示:

  

 

3.測試用例

代碼實現完了,怎麼能少的了測試用例呢,下方就是我們要使用的測試用例。武器使用者可以自由切換生產武器的工廠,其實這一點類似於“策略模式”,不過不是策略模式,可以添加上一下相應的方法,將上述實現融進策略模式,再次就不做過多贅述了。下方就是我們的測試用例:

   

 

五、“工廠方法”+“抽象工廠”模式

緊接著,我們要做一件事情,就是保留第四部分中的“裝飾者”、“抽象工廠”,在此基礎上添加上“工廠方法”模式。也就是我們要實現裝飾者+抽象工廠+工廠方法,是不是聽起來很興奮呢。上面也說了,還可以融入“策略模式”,這個就留給讀者去做了。在本部分,我們將使用“工廠方法”模式來重寫武器的使用者WeaponUser。這一部分很好的說明瞭工廠方法模式與抽象工廠模式的不同,而且兩者可以結合在一起使用。

 

1、設計“類圖”

下方這個“類圖”就比較複雜了,不過不用擔心,下方是在上一部分擴展而來的。與第四部分的類圖對比一下,是不是只添加了黃框中的內容呢?確實如此,本部分在上面設計的基礎上,我們添加了“工廠方法模式”,關於工廠方法模式的具體內容請參見本篇博客中的第三部分。紅框中的裝飾者模式與綠框中的“抽象工廠模式”是不變的。我們只是使用“工廠方法模式”重寫了第四部分中的WeaponUser類。將WeaponUser類中選擇工廠的代碼推遲到了相應的子類中,有子類的工廠方法來完成相應工廠的創建

   

 

2.代碼實現

如果你看類圖比較抽象的話,那麼我們就看代碼。在實現中我們隊WeaponUser類進行的“工廠方法”的重寫。提取了WeaponUser的介面WeaponUserType(對應著上述類圖中的WeaponUser)。下方就是WeaponUserType的代碼實現,在提取介面中,其中有一個“工廠方法”,那就是createWeaponFactroy(),如下所示:

   

 

為了代碼的復用性,我們為上述介面中一些方法提供預設的實現。當然在Swift中我們使用extension為協議添加預設實現。在下方的延展中我們給出了fireWithType()和createWeaponWithType()的預設實現。具體做法如下所示。

    

緊接著我們要實現相應的WeaponUserType的子類,在子類中通過“工廠方法”來指定兵工廠,具體實現如下:

    

 

3.測試用例

至此,我們又在“裝飾者”、“抽象工廠”的基礎上添加上了“工廠方法模式”。通過上面的案例我們不難看出,“抽象工廠”是工廠的集合,“工廠方法”會指定使用工廠集合中某一個特定的工廠。下方是對本部分案例的測試用例,具體如下:

   

 

今天的博客篇幅有限,就先到到這兒了,其實上述示例還是可以加入“策略模式”的,感興趣的讀者可以嘗試一下。

今天博客中的代碼仍然會在Github上進行分享,分享地址為:https://github.com/lizelu/DesignPatterns-Swift

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 直接看這裡,省的搬過來。。 ...
  • 1 Private Sub SaveAndClear() 2 3 Dim Header, Deatil, Order As Range 4 Dim lastrow1, lastrow2 As Long 5 Dim i As Integer 6 7 lastrow1 = Sheet1.[B65536] ...
  • python轉換已轉義的字元串 有時我們可能會獲取得以下這樣的字元串: Python代碼 >>> a = '{\\"name\\":\\"michael\\"}' >>> print a {\"name\":\"michael\"} Python代碼 Python代碼 那麼該如何將其轉換為一個字典呢 ...
  • Php代碼 <?php /** * 助手類 * @author www.shouce.ren * */ class Helper { /** * 判斷當前伺服器系統 * @return string */ public static function getOS(){ if(PATH_SEPARAT ...
  • 返回目錄 再說概念 這兩個模式確實有點相似,都為了實現程式的解耦產生的,觀察者一般又稱發佈/訂閱模式,它一般是有一個主題對象,然後有多個訂閱者去關註它,當它的狀態發生變化時,會自動通知這些訂閱者;而消費者模式類似一個緩存隊列的概念,它也稱為生產者/消費者模式,生產者只負責生產數據不去做處理(緩解高並 ...
  • 代理模式(Proxy) 定義 代理模式(Proxy),為其他對象提供一種代理以控制對這個對象的訪問。 類圖 描述 Subject,定義了ConcreteSubject和Proxy的共用介面,這樣就可以在任何使用ConcreteSubject的地方使用Proxy; Proxy,保存一個Concrete ...
  • 前不久公司請來了位互聯網界的技術大牛跟我們做了一次大型網站架構的培訓,兩天12個小時信息量非常大,知識的廣度和難度也非常大,培訓完後我很難完整理出全部聽到的知識,今天我換了個思路是回味這次培訓,這個思路就是通過本人目前的經驗和技術水平來思考下大型網站技術演進的過程。 首先我們要思考一個問題,什麼樣的 ...
  • 當需要將一個複雜的對象的構建與它的表示分離,使得同樣的構建過程可以創建不同的表示,就可以使用建造者模式。 在建造者模式中,用戶只需要指定需要建造的類型就可以得到它們,而建造的具體過程和細節是不需要知道的。 下麵使用建造小人,舉例說明該模式: 首先創建不同的建造者: 然後,定義指揮者,該指揮者定義了建 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...