Factory pattern 工廠模式

距離上一篇 Strategy pattern 策略模式已經兩個多月了，一直拖到現在才生出這篇文章...orz。
其實這篇工廠模式應該要當作第一篇 Design pattern 的文章會比較好，因為這個模式很容易懂，但是工廠模式中又細分出一些其他類似的模式，例如抽象工廠模式，所以我把一些相關的資料都讀了一遍後，分三篇作介紹。
工廠模式最主要的精神就是將 new Class 這個動作另外封裝成一個 Factory Class，這個Factory Class 專門負責實體化這些類別。
特地這樣做有什麼好處呢?
舉個例子，假如我們現在有兩個繼承 Product 的類別，它們擁有共同的方法 Operation()

一般來講，我們如果要實體化 ProductA 或 ProductB 的話，會這樣寫:

   1: namespace FactoryPattern
   2: {
   3:     class Program
   4:     {
   5:         static void Main(string[] args)
   6:         {
   7:             Product product = new ProductA();
   8:  
   9:             product.Operation();
  10:         }
  11:     }
  12: }
這樣做有什麼缺點呢?
如果我 product 型別要換成 ProductB 的話，就需要把第7行的 new ProductA() 改成 new ProductB()，若是繼承 Product 的類別一多，以後程式碼的維護上會很麻煩。

簡單工廠模式 Simple Factory Pattern (又稱靜態工廠模式 Static Factory Pattern):


按照上圖，將擁有共同介面類別的實體化動作封裝在 Factory 內，程式就可以在執行時動態決定要實體化哪個類別了。

Factory class:
   1: namespace SimpleFactoryPattern
   2: {
   3:     public class Factory
   4:     {
   5:         public Product CreateProduct(string name)
   6:         {
   7:             switch (name)
   8:             {
   9:                 case "ProductA":
  10:                     return new ProductA();
  11:                 case "ProductB":
  12:                     return new ProductB();
  13:                 default:
  14:                     return null;
  15:             }
  16:         }
  17:     }
  18: }


Client:
   1: using System;
   2:  
   3: namespace SimpleFactoryPattern
   4: {
   5:     class Program
   6:     {
   7:         static void Main(string[] args)
   8:         {
   9:             // productName可以動態決定要實體化的類別
  10:             string productName = "ProductA";
  11:         
  12:             Factory productFactory = new Factory();
  13:         
  14:             Product product = productFactory.CreateProduct(productName);
  15:  
  16:             product.Operation();
  17:         }
  18:     }
  19: }

到這裡可以看看使用 Factory 後，和使用之前的程式碼做比較，最大的差別就是現在可以靠變數來決定要實體化的類別了，若是需要改成 ProductB 的話，只需要將 productName 的值改成 "ProductB" 就行了。

如果覺得上面的 Factory productFactory = new Factory(); 這行有點礙眼的話，還可以將程式碼更簡單話一點，就是把 Factory class 的 CreateProduct() 方法改成 static:

   1: public static Product CreateProduct(string name)

這樣就可以直接跳過 new Factory() 的步驟，直接呼叫 CreateProduct() 方法:

   1: static void Main(string[] args)
   2: {
   3:      string productName = "ProductA";
   4:                 
   5:      Product product = Factory.CreateProduct(productName);
   6:  
   7:      product.Operation();
   8: }

使用簡單工廠模式雖然方便，但也是有缺點的。
如果每次新增一個 Product 子類別後，都必須修改 Factory class 中 CreateProduct() 的 switch 判斷式的話，這樣做不符合物件導向設計的 Open-Closeed Principle(開放-封閉原則) 精神。
什麼是開放-封閉原則呢?
簡單說就是程式容易擴充新功能，但是不用修改原始碼的意思。
如果因為要擴充 ProductC class 進來，而修改了 Factory class 的話，這樣的做法並不是很好，所以比較正統的工廠模式有另一種寫法，就是接著下一篇要介紹的工廠方法模式。


工廠方法模式 Factory Method Pattern:

要解決簡單工廠模式的問題，工廠方法模式的做法是將 Factory 類別抽象化，讓每個 Product 子類別都有屬於自己的工廠類別，如上圖所示。


Factory interface:
   1: namespace FactoryMethodPattern
   2: {
   3:     public interface Factory
   4:     {
   5:         Product CreateProduct();
   6:     }
   7: }


ProductFactoryA class:
   1: namespace FactoryMethodPattern
   2: {
   3:     public class ProductFactoryA : Factory
   4:     {
   5:         public Product CreateProduct()
   6:         {
   7:             return new ProductA();
   8:         }
   9:     }
  10: }


ProductFactoryB class:
   1: namespace FactoryMethodPattern
   2: {
   3:     public class ProductFactoryB : Factory
   4:     {
   5:         public Product CreateProduct()
   6:         {
   7:             return new ProductB();
   8:         }
   9:     }
  10: }


Client:
   1: using System;
   2:  
   3: namespace FactoryMethodPattern
   4: {
   5:     class Program
   6:     {
   7:         static void Main(string[] args)
   8:         {
   9:             // ProductA
  10:             Factory productFactoryA = new ProductFactoryA();
  11:             Product productA = productFactoryA.CreateProduct();
  12:             productA.Operation();            
  13:             
  14:             // ProductB
  15:             Factory productFactoryB = new ProductFactoryB();
  16:             Product productB = productFactoryB.CreateProduct();            
  17:             productB.Operation();
  18:         }
  19:     }
  20: }

這樣就解決簡單工廠的擴充問題了，如果需要增加 ProductC 的話，只需要加入 繼承 Product 的ProductC class 和 繼承 Factory 的 ProductFactoryC class 就可以了，不需要動到其他程式碼。


抽象工廠模式 Abstract Factory Pattern:

最後要介紹的是抽象工廠模式，這個模式其實跟上面的工廠方法是差不多的，只是增加了第二組Product的概念，我們來看看它的定義:
抽象工廠模式，提供一個建立一系列相關物件的介面，而無需指定它們具體的類別。
從上圖來看，我們有兩組產品，Product1 和 Product2，可以把它們想像成Office的Word和Excel，這兩組產品如果要跨平台到Mac的話，就會分支出Windows版和Mac版的，但是軟體做的事情是一樣的，所以它們繼承了共同的方法，如下圖:


看完上圖後，可以看出每個產品都有Windows和Mac兩種系列，所以我們可以為他們寫兩個工廠類別，一個專門負責生產Windows，一個專門負責生產Mac的產品，來看看程式碼:


Factory interface:
   1: namespace AbstractFactoryPattern
   2: {
   3:     public interface Factory
   4:     {
   5:         // 想像成CreateWindowsProduct()
   6:         Product1 CreateProduct1();
   7:  
   8:         // 想像成CreateMacProduct()
   9:         Product2 CreateProduct2();
  10:     }
  11: }


ProductFactoryA class:
   1: namespace AbstractFactoryPattern
   2: {
   3:     // 想像成WordFactory
   4:     public class ProductFactoryA : Factory
   5:     {
   6:         public Product1 CreateProduct1()
   7:         {
   8:             // 生產Windows的Word
   9:             return new Product1A();
  10:         }
  11:  
  12:         public Product2 CreateProduct2()
  13:         {
  14:             // 生產Mac的Word
  15:             return new Product2A();
  16:         }
  17:     }
  18: }


ProductFactoryB class:
   1: namespace AbstractFactoryPattern
   2: {
   3:     // 想像成ExcelFactory
   4:     public class ProductFactoryB : Factory
   5:     {
   6:         public Product1 CreateProduct1()
   7:         {
   8:             // 生產Windows的Excel
   9:             return new Product1B();
  10:         }
  11:  
  12:         public Product2 CreateProduct2()
  13:         {
  14:             // 生產Mac的Excel
  15:             return new Product2B();
  16:         }
  17:     }
  18: }


Client:
   1: namespace AbstractFactoryPattern
   2: {
   3:     class Program
   4:     {
   5:         static void Main(string[] args)
   6:         {
   7:             // Word工廠
   8:             Factory productFactoryA = new ProductFactoryA();            
   9:             // 製造Windows和Mac版本的Word
  10:             Product1 product1A = productFactoryA.CreateProduct1();            
  11:             Product2 product2A = productFactoryA.CreateProduct2();
  12:             // 跑兩種版本的Word
  13:             product1A.Operation();
  14:             product2A.Operation();
  15:  
  16:             // Excel工廠
  17:             Factory productFactoryB = new ProductFactoryB();
  18:             // 製造Windows和Mac版本的Excel
  19:             Product1 product1B = productFactoryB.CreateProduct1();
  20:             Product2 product2B = productFactoryB.CreateProduct2();
  21:             // 跑兩種版本的Excel
  22:             product2B.Operation();
  23:             product1B.Operation();
  24:         }
  25:     }
  26: }

這樣就完成抽象工廠模式了，將 Factory 抽象化後， Client端就能利用多型的方法實體化Product，而不需要知道具體的類別就能操作它，這就是抽象工廠的優點。


進階技巧:
到這邊其實已經把工廠模式都介紹完了，不過其實上面的抽象工廠還是有不完美的地方，例如我們現在加入了一個新的Product系列ProductC(可以想像成Linux版本的Office)，那麼我們除了要寫 Product1C 跟 Product2C 這些基本的類別外，還要再為它們新增一個 ProductFactoryC 的類別，讓人覺得有一些麻煩。
這邊要介紹大話設計模式一書中作者提供的一個技巧，可以將工廠模式再修改的更加完美。

看到上圖後，可以發現我們將 Factory 的抽象化拿掉了，變回最初的簡單工廠模式，這時候的 Factory 會變成這樣:


Factory class:
   1: using System;
   2:  
   3: namespace SimpleAbstractFactoryPattern
   4: {
   5:     public class Factory
   6:     {
   7:         public static Product1 CreateProduct1(string name)
   8:         {
   9:             switch (name)
  10:             {
  11:                 case "Product1A":
  12:                     return new Product1A();
  13:                 case "Product1B":
  14:                     return new Product1B();
  15:                 default:
  16:                     throw new Exception();
  17:             }
  18:         }
  19:  
  20:         public static Product2 CreateProduct2(string name)
  21:         {
  22:             switch (name)
  23:             {
  24:                 case "Product2A":
  25:                     return new Product2A();
  26:                 case "Product2B":
  27:                     return new Product2B();
  28:                 default:
  29:                     throw new Exception();
  30:             }
  31:         }
  32:     }
  33: }

這樣寫的話，之前才提到的開放-封閉原則的缺點不是又出現了嗎?
如果增加了一個新的 ProductC 類別的話，就需要在 Factory 裡面增加新的 switch case 分支條件，不容易擴充的問題就出現了。
這裡要介紹 C# 跟 JAVA 都有提供的一個機制，Reflection(反射)，它可以直接依照 class 的名稱來實體化類別，我們直接來看看用Reflection機制修改後的 Factory 程式碼吧:


Factory class:
   1: using System;
   2: using System.Reflection;
   3:  
   4: namespace SimpleAbstractFactoryPattern
   5: {
   6:     public class Factory
   7:     {
   8:         // 專案的namespace
   9:         private static readonly string AssemblyName = "SimpleAbstractFactoryPattern";
  10:  
  11:         public static Product1 CreateProduct1(string name)
  12:         {
  13:             // 如果傳進來的name是"Product1A"
  14:             // 那className就等於SimpleAbstractFactoryPattern.Product1A
  15:             string className = AssemblyName + "." + name;
  16:  
  17:             // 這裡就是Reflection，直接依照className實體化具體類別
  18:             return (IProduct1)Assembly.Load(AssemblyName).CreateInstance(className);
  19:         }
  20:  
  21:         public static Product2 CreateProduct2(string name)
  22:         {
  23:             string className = AssemblyName + "." + name;
  24:  
  25:             return (IProduct2)Assembly.Load(AssemblyName).CreateInstance(className);
  26:         }
  27:     }
  28: }


Client:
   1: namespace SimpleAbstractFactoryPattern
   2: {
   3:     class Program
   4:     {
   5:         static void Main(string[] args)
   6:         {
   7:             // 生產產品A
   8:  
   9:             Product1 product1A = Factory.CreateProduct1("Product1A");
  10:             Product2 product2A = Factory.CreateProduct2("Product2A");
  11:  
  12:             product1A.Operation();
  13:             product2A.Operation();
  14:  
  15:             // 生產產品B
  16:  
  17:             Product1 product1B = Factory.CreateProduct1("Product1B");
  18:             Product2 product2B = Factory.CreateProduct2("Product2B");
  19:  
  20:             product2B.Operation();
  21:             product1B.Operation();
  22:         }
  23:     }
  24: }

看到了嗎!?這樣就算加入了其他 Product 子類別後，也不需要修改 Factory 的程式碼，只要在 CreateProduct() 方法內傳入要實體化的類別名稱就可以了，相當方便吧。
範例檔案:
參考資料:

留言

張貼留言

這個網誌中的熱門文章

全遠端工作

圖片
每周分享第 21 期 全遠端工作 原文標題：All Remote 原文網址：https://about.gitlab.com/company/culture/all-remote/ 原文作者：GitLab GitLab 是一間實行 全遠端 （All Remote）的公司， 團隊成員 遍布全球 50 多個國家。 這裡 有介紹一些 GitLab 的工作原理。 遠端宣言 全遠端工作提倡： 從世界各地招聘和工作，而不是從都市地帶 彈性工時，勝過固定工時 寫下和記錄知識，勝過口頭傳授 寫下流程，勝過在職培訓 公開分享資訊，勝過僅知原則（need-to-know access，僅給予完成一件任務所需要知道的事項即可） 開放所有文件供任何人編輯，勝過自上而下的文件控制 非同步通訊，勝過同步通訊 工作的成果，勝過投入的工時 正式的溝通管道，勝過非正式的溝通管道 正式溝通 vs 非正式溝通（ 來源 ） 為什麼需要遠端？ 遠端不是一個需要克服的挑戰。這是一個明顯的商業優勢。 — Victor, Product Manager, GitLab 從節省辦公空間的成本到員工的日常生活更加彈性，全遠端工作為組織及其員工提供了許多好處。但我們也體認到，並非所有人都適合成為一家全遠端的公司。 以下是一些優點和缺點。 優點 對於員工 日常生活更加彈性（小孩、父母、朋友、雜務、運動、快遞） 不會浪費時間、精力和金錢在通勤上（捷運和公車、油價、維修保養、收費站等） 減少接觸同事的病菌 減少被打斷的狀態，提高 生產力 能夠在不請假的情況下遊歷各地（家庭、娛樂等） 自由移動 有些人發現遠端更容易與難搞的同事溝通 減少入職可能會有的社交壓力 在家吃飯（有時）更好、更便宜 某些國家的稅收可能更便宜 不用煩惱今天穿什麼 從家庭時間到旅行計劃，有很多關於遠端工作是如何影響全球 GitLab 團隊成員生活的 例子和...
閱讀完整內容

影響我一生的十大遊戲（一）

圖片
每周分享第 19 期 影響我一生的十大遊戲（一） 自 1989 年的平成元年算起，持續了約 30 年的「平成時代」已於今年 4 月畫下句點，5 月起由新年號「令和」正式接班。 日本遊戲媒體 週刊ファミ通 日前 公布 由讀者票選的「平成最佳遊戲」前三名經典作品。 來源： ファミ通.com 拿下第一名的是 1995 年在 SFC（俗稱： 超任 ）平台發售的《 超時空之鑰 》。本作受到 30 歲以上玩家（包括我）一致壓倒性支持，高票獲選。 來源： ヤフオク 《超時空之鑰》是由 SQUARE （當時尚未合併 SQUARE ENIX ）負責製作發行，《 七龍珠 》作者 鳥山明 、《 勇者鬥惡龍 》之父 堀井雄二 ，以及《 太空戰士 》之父 坂口博信 聯手打造的夢幻級 RPG。無論是劇情、美術、系統或音樂，放到今天來看仍是經典的不朽名作。 創新的時空旅行與多重結局成為不少玩家一生難忘的回憶（來源： ヤフオク ） 作為一路走過昭和、平成、令和時代的三朝元老級玩家，見證了這 30 年間五花八門的遊戲作品問世。最近看了 YouTube 頻道 攻壳 Gamker 的《 十大影響我的遊戲 》影片之後，也想來寫一系列「影響我一生的十大遊戲」文章。 第十位：熱血行進曲（FC） ...
閱讀完整內容

無限環境（ㄧ）Netlify Deploy Previews

圖片
大綱 什麼是「無限環境」？ 什麼是 Netlify Deploy Previews？ 快速入門指南 步驟一、建立 React 網站 步驟二、建立 GitHub repository 步驟三、註冊＆配置 Netlify ⭐️ 最終步驟、玩轉 Deploy Previews ⭐️ 總結 附錄 參考資料 什麼是「無限環境」？ 大家常用的 GitHub flow 其實有一個常常被忽略的重點 —— 合併前部署。 我自己在前端開發的 Code Review 上，常常碰到下列兩個問題： PR 合併、部署到 staging 或 production 環境之後，才發現程式碼有問題 為了避免第一個問題發生，就必須先 checkout PR 到 local 環境，然後經過一系列繁瑣的步驟跑起來，最後才能開始驗收和測試 為了解決上述問題，就需要引入無限環境的概念。 所謂的無限環境，就是自動將目前 PR 中的最新 commit，部署到一個臨時環境中，並返回該環境的 URL 網址。[1] 如果能實現這個條件，將為開發團隊帶來兩點好處： Reviewer 有任何懷疑時，便可以直接在預覽環境中驗證，而非憑空猜疑。 Reviewer 也可以放心大膽的驗證自己的懷疑，不需要在 local 開發環境耗時費力地切換。 接下來我會寫三篇「無限環境」系列的文章，介紹一些可以達成這個目的的工具。 這是第一篇文章，介紹如何透過 Netlify 的 Deploy Previews 服務，建立靜態網頁的無限環境。 什麼是 Netlify Deploy Previews？ Netlify 是一個類似 Heroku 的 All-in-one PaaS ，提供各種現代 web 專案會用到的自動化服務，例如：靜態網站部署、CDN、持續交付和一鍵配置 HTTPS 等。 其中 Deploy Previews 這項服務，可以將 GitHub repository 中的每個 pull request 部署到 唯一 的 URL，與 staging 和 production 環境的完全不同。你和你的團隊可以在合併到主分支、並且部署到正式環境之前，提前看到更改的外觀以及驗收功能是否正確。 快速入門指南 這篇文章會以時下最流行的 Create React App 為例，示範如何實現 React ...
閱讀完整內容