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() 方法內傳入要實體化的類別名稱就可以了，相當方便吧。
範例檔案:
參考資料:

留言

張貼留言

這個網誌中的熱門文章

COSCUP 2012

今年很幸運的有搶到入場資格，這也是小弟第一次參加 COSCUP ，趁現在剛結束滿腔熱血的狀態下來寫篇心得文。 今年 COSCUP 一共有兩天的行程，在中研院人文館舉辦，每個時段都有 3~4 場的分享，不過常常碰到某個時段三場都想聽，也常常碰到某個時段的題目都沒興趣...orz Day1 第一天忘了做筆記，只好憑記憶跟拿些圖來湊一湊 我的專屬識別證唷>.^ 早上第一場是微軟傳教士分享的 Windows Azure 感覺還不錯，而且有繁體中文的介面。 第二場我去聽了 Fred 的 Nodee.js OS，不過我覺得他自己改的 Linux 比較炫。 第三場請到 Penk 大大來 demo 他的平板 UI，印象深刻的一句話是 科技業是唯一比女行時尚還追求時尚的行業 我的解讀是幹這行每天都在學新技術 囧.. 第四場超讚，講者 demo 他用 javascript 寫的超任模擬器，眼淚都快飆出來了，而且老師很幽默: 目前國外有人正在研究如何用 javascript 寫出一個超任模擬器，如果他成功，那會是全世界第三個，因為前面兩個被我寫出來了XDDD 接下來的下午場雖然都有去聽，可是比較沒有什麼印象的點，只記得最後閃電秀的大大們XD，你們實在太讚了! Day2 難得有位置，明明很晚到... 第一場請到廣達的 Ted 先生，本來以為會很無聊，但從頭聽到尾，學到蠻多東西的: 研發的目的 1.不想被外界surprise 2.想給外界surprise   不相信外星人就無法創造飛行車   要把複雜的東西變簡單其實是最不簡單的   設計一個你最討厭的東西 試著把它做好 第二場去聽 Tool Objects in jQuery，主要重點: 用 Queue 取代巢狀 Callback Deferred 可以看做是 Call by future  $.when 可以用來管理複數非同步的結果  pipe 跟 when 的關係可以看作串聯與並聯 一些 Callback 常用的 function: add fire once memory unique stopOnFalse differed 第三場的場次是我最掙扎的，有Heroku，有Emacs，有Twitter Bootstrap，還有手
閱讀完整內容

Hahow 為什麼沒有 iOS App

圖片
大綱 前言 Hahow 為什麼沒有 iOS App？ 為什麼有了「App 內購買」還是被拒絕？ 為什麼 Hahow 要使用「消耗型項目」IAP？ 為什麼 Udemy 可以使用「消耗型項目」IAP？ Hahow iOS App 接下來的計畫？ 結語 前言 最近看到一篇 The Verge 報導 ，Apple 的律師要求 App Store 的前任經理停止發行《App Store Confidential》這本書，因為此書透露了「重大的商業機密」，違反了員工與公司簽訂的合約。 但是此書的作者 Sadowski 表示，這本書的很多內容其實是大家都知道的，例如：應用程式必須將使用者轉化為 Apple 的 付費客戶。 來源 appleinsider 眾所周知，Apple 的 App Store 平台審核機制封閉，很多東西是他們說的算。 作為一位曾經參與 Hahow App 的開發人員，看到這一篇報導感觸很深，滿肚子苦水不吐不快。 許多 Hahow 的使用者常常詢問，為什麼 Android 的 App 已經上架這麼久了，iOS App 卻還看不見影呢？ https://hahow.app Hahow 為什麼沒有 iOS App？ 其實 iOS App 一直都是與 Android App 同步開發的。 最早可以回朔到 2017 年 10 月，當初 Web 使用者不斷反應，希望可以在手機上，下載 Hahow 的課程，方便通勤時間也能離線觀看。 於是我自己利用公司讀書會的機會，嘗試使用 React Native 開發了一個 Hahow App 的原型（Prototype），簡單演示了「下載離線觀看」和「通知」兩個手機上才能做到的功能。 Prototype 讀書會簡報 也因此，成功說服了幾位頭頭，於 2018 年 2 月正式投入開發 Hahow App。 並於 2018 年 6 月，順利在 Google Play 上架 Android App。 有關於我們如何用 Expo 這個 React Native SDK 開發 App、踩過哪些坑，以及專案的 Scrum 怎麼跑之類的，會再另外找時間分享一篇《Hahow 如何開發 Android App》文章，這裡就先不多贅述。 Go
閱讀完整內容

swfobject - 網頁輕鬆嵌入Flash

Flash在網頁上的應用已經越來越普遍了，未來一樣占有一席之位，但是從以前到現在，對於發佈Flash到網頁上常常碰到一些不必要的問題，例如XP SP2更新後，IE瀏覽器上方會出現檔掉的訊息，或是Flash外框出現虛線，需要滑鼠點一下才能開始動作等...，而且使用者並未安裝Flash Player的情況下或版本太低都會無法順利的瀏覽。 最近剛好看到一個不錯的東西，就是這次要介紹的swfobject，一般我們要嵌入swf到HTML時，通常會寫的語法如下: < object id ="FlashID" classid ="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width ="300" height ="120" > < param name ="movie" value ="test.swf" /> < param name ="quality" value ="high" /> < param name ="wmode" value ="opaque" /> < param name ="swfversion" value ="6.0.65.0" /> </ object > 上面的程式碼使用到<object>標籤，早一點的甚至還要再寫<embed>才能動作，因為IE跟其他瀏覽器的種種原因，使得這種寫法不但又臭又長，也不符合標準。 那使用swfobject有什麼好處呢?我們繼續看下去吧。 首先我們得先去swfobject的網頁 http://code.google.com/p/swfobject/ ，然後下載目前的最新版本 swfobject_2_2.zip 。
閱讀完整內容