簡單工廠模式Simple Factory Pattern【Simple Factory Pattern】是設計模式里最簡單的一個模式，又叫靜態工廠模式【Static Factory Pattern】，這個模式沒有收錄在GOF 23 個模式中，因為他非常簡單，在項目中使用也非常廣泛，所以就用它來開篇。
一、簡單工廠模式定義：
簡單工廠模式(Simple Factory Pattern)：定義一個工廠類，它可以根據參數的不同返回不同類的實例，被創建的實例通常都具有共同的父類。因為在簡單工廠模式中用於創建實例的方法是靜態(static)方法，因此簡單工廠模式又被稱為靜態工廠方法(Static Factory Method)模式，它屬於類創建型模式。
二、簡單工廠模式結構圖
簡單工廠結構圖
從簡單工廠結構圖中我們可以看出它包含三個角色：
1. IProduct (抽象產品角色）：
它是工廠類所創建的所有對象的父類，封裝了各種產品對象的公有方法，它的引入將提高系統的靈活性，使得在工廠類中只需定義一個通用的工廠方法，因為所有創建的具體產品對象都是其子類對象。抽象產品可以使用接口和抽象類來來實現。
2. ConcreteProduct （具體產品角色）：
它是簡單工廠模式的創建目標，所有被創建的對象都充當這個角色的某個具體類的實例。每一個具體產品角色都繼承了抽象產品角色，需要實現在抽象產品中聲明的抽象方法。在簡單工廠模式中，客戶端通過工廠類來創建一個產品類的實例，而無須直接使用new關鍵字來創建對象，它是工廠模式家族中最簡單的一員。 在使用簡單工廠模式時，首先需要對產品類進行重構，不能設計一個包羅萬象的產品類，而需根據實際情況設計一個產品層次結構，將所有產品類公共的代碼移至抽象產品類，並在抽象產品類中聲明一些抽象方法，以供不同的具體產品類來實現。
3. Factory （工廠角色）：
這個角色就是工廠類，他是工廠模式的核心，負責實現創建所有產品實例的內部邏輯；工廠類可以被外界直接調用，創建所需的產品對象；在工廠類中提供了靜態的工廠方法factoryMethod()，它的返回類型為抽象產品類型Product。
三、簡單工廠的代碼實現
public interface IProduct { void SomeMethod(); } public class ConcreteProductA : IProduct { public void SomeMethod() { Console.WriteLine("I am product A"); } } public class ConcreteProductB : IProduct { public void SomeMethod() { Console.WriteLine("I am product B"); } } public class Factory { public static IProduct Create(string productType) { IProduct product; switch (productType.ToUpper()) { case "A": product = new ConcreteProductA(); break; case "B": product = new ConcreteProductB(); break; default: throw new ArgumentException("Invlid Argument.", nameof(productType)); } return product; } }
客戶端調用：
static void Main() { var product = Factory.Create("A"); product.SomeMethod(); product = Factory.Create("B"); product.SomeMethod(); Console.ReadKey(); }
輸出結果：
四、需求改變促使代碼重構得到簡單工廠模式
甲方提出了這樣一個需求：要求做一個音頻播放器。只需要支持播放WMA格式的文件就好了。開發人員拿到需求后竊喜，這么簡單個需求，簡直就是毛毛雨啦。好了編碼開始。
很快代碼就編寫好了：
public class Audio { public void Play(string name) { Console.WriteLine("Start playing..."); Console.WriteLine($"The song name is: [{name}]"); Console.WriteLine(".........."); } } [Description("1.2. Simple Factory")] public class App { static void Main() { Audio audio=new Audio(); audio.Play("take me to your heart"); Console.ReadKey(); } }
輸出結果如下：
甲方看到軟件試用一翻感覺不錯很滿意，趕緊給開發人員支付了開發費用。將軟件投放市場。
很長一段時間，市場放映不錯，這個音頻播放器市場占有率提高很快。但是有一天一種新的音頻格式誕生了，WAV格式的音頻文件越來越多了，用戶拿到WAV的音樂沒辦法使用這個播放器播放了，甲方從市場上得到了很多反饋，於是，甲方決定升級這款音頻播放器軟件使其支持這種新的WAV格式的音頻文件。 甲方找到了開發人員要求增加WAV格式文件的播放。開發人員拿到需求后趕緊開始寫代碼。很快代碼寫出來了：
public class WmaFile { public void Play(string name) { Console.WriteLine("Start playing wma file..."); Console.WriteLine($"The song name is: [{name}]"); Console.WriteLine(".........."); } } public class WavFile { public void Play(string name) { Console.WriteLine("Start playing wav..."); Console.WriteLine($"The song name is: [{name}]"); Console.WriteLine(".........."); } } [Description("1.2. Simple Factory")] public class App { static void Main() { Console.WriteLine("Please input a or m"); var input = Console.ReadKey(); if (input != null) { if (input.Key == ConsoleKey.A) { WavFile wav = new WavFile(); wav.Play("take me to your heart.wav"); } else if (input.Key == ConsoleKey.M) { WmaFile audio = new WmaFile(); audio.Play("take me to your heart.wma"); } } Console.ReadKey(); } }
運行軟件如圖：
甲方拿到軟件測試一翻，很滿意，趕緊投入市場，反響強烈，市場占有率進一步提高。
隨着時間的推移一種新的音樂格式出現了，mp3 格式文件的音樂出現了，他的文件占用存儲小， 音質好，原來一張光盤只能裝5首wma或者wav格式的音樂文件，現在一張光盤可以裝30首mp3了。這簡直就是一場革命， 但是甲方目前的音頻播放播放器不支mp3格式， 甲方的幾個競爭對手已經搶先一步支持了mp3的播放，甲方的音頻播放器的市場占有率在急劇下降，甲方坐不住了，他來不及從市場上去拿反饋了，趕緊找到開發人員，讓開發人員趕緊加班加點開發出支持mp3格式文件，不然他的播放器就要被這個瞬息萬變的市場所淘汰。開發人員接到這個命令也是不敢怠慢。趕緊投入工作。
當開發人員打開已經實現的代碼時陷入了沉思，再加一個類開發mp3 格式文件的播放功能嗎？ 如果這樣寫下去的話代碼會變得很難維護和擴展了，現在技術發展這么快，指不定哪一天有冒出一個什么格式，再這樣堆積木似的一直寫下去自己都不想看自己寫的代碼了。 於是他決定重構代碼，但是怎么重構呢？ 突然腦海中閃過了昨天不是在看《設計模式》嗎？里面不是有個簡單工廠模式嗎？這個模式似乎很適合中中場景，好的就用這個模式, 把播放音樂的功能提出一個接口， 然后創建出繼承這個接口的各個格式文件的具體播放類，然后在創建一個靜態工廠根據客戶的音樂文件格式選擇創建那個具體的類來播放當前的文件。 有了這個思路那就趕緊動手重構代碼吧。 很快代碼重構完成了：
public interface IAudio { void Play(string name); } public class Wma : IAudio { public void Play(string name) { Console.WriteLine("Start playing wma file..."); Console.WriteLine($"The song name is: [{name}.wma]"); Console.WriteLine(".........."); } } public class Wav : IAudio { public void Play(string name) { Console.WriteLine("Start playing wav file..."); Console.WriteLine($"The song name is: [{name}.wav]"); Console.WriteLine(".........."); } } public class Mp3 : IAudio { public void Play(string name) { Console.WriteLine("Start playing mp3..."); Console.WriteLine($"The song name is: [{name}.mp3]"); Console.WriteLine(".........."); } } public class AudioFactory { public static IAudio Create(string songType) { IAudio audio; switch (songType.ToUpper()) { case "A": audio = new Wav(); break; case "M": audio = new Wma(); break; case "P": audio = new Mp3(); break; default: throw new ArgumentException("Invalid argument", nameof(songType)); } return audio; } } [Description("1.2. Simple Factory")] public class App { static void Main() { Console.WriteLine("Please input a or m or p"); var input = Console.ReadKey(); if (input != null) { IAudio audio = AudioFactory.Create(input.Key.ToString()); audio.Play("take me to your hert"); } Console.ReadKey(); } }
輸出結果：
好了這個音頻播放器支持mp3了， 甲方非常高興，趕緊把這個新的版本投入市場。甲方通過這次升級挽回了一些他在音頻播放市場上的一些頹勢。
通過這么一次突然的襲擊使開發人員收獲不少，最起碼學到了一種設計模式（simple facfory）的使用，也是成就滿滿。 但是開發人員還是心有余悸，如果哪一天突然有出來個什么新的格式是不是又要加班加點的搞上一陣子。 他想如果在不改變這個軟件已有代碼的情況下，來擴展，比方說，新增了一個類型，但是不需要修改代碼通過寫一個類或者增加一些配置就可以實現這個完美支持新的格式的音頻文件？（這不是OCP原則嗎？ ） 那么這個問題Simple Factory Pattern 能做到嗎？ 問題先留着，隨着模式學習的深入， 讓我們慢慢在后面的學習中去尋找答案。
五、簡單工廠模式的優點
- 工廠類含有必要的判斷邏輯，可以決定在什么時候創建哪一個產品類的實例，客戶端可以免除直接創建產品對象的責任，客戶程序不需要產品的具體生產細節；簡單工廠模式通過這種做法實現了對責任的分割，它提供了專門的工廠類用於創建對象。
- 客戶端無須知道所創建的具體產品類的類名，只需要知道具體產品類所對應的參數即可，不需要知道產品是怎么創建的。
- 通過引入配置文件，可以在不修改任何客戶端代碼的情況下更換和增加新的具體產品類，在一定程度上提高了系統的靈活性。
- 簡單工廠將創建產品的職責放在了單獨的靜態工廠中去處理和維護一定長度上體現了SRP原則。
六、簡單工廠模式的缺點
- 由於工廠類集中了所有產品創建邏輯，一旦不能正常工作，整個系統都要受到影響。
- 使用簡單工廠模式將會增加系統中具體產品類的個數，在一定程序上增加了系統的復雜度和理解難度。
- 系統擴展困難，一旦添加新產品就不得不修改工廠邏輯，在產品類型較多時，有可能造成工廠邏輯過於復雜，不利於系統的擴展和維護。
- 由於在增加新的產品的時候簡單工廠模式必須要修改靜態的工廠方法，所以它違背了OCP原則。
七、工廠模式的使用場景
在以下情況下可以使用簡單工廠模式：
- 工廠類負責創建的對象比較少：由於創建的對象較少，不會造成工廠方法中的業務邏輯太過復雜。
- 客戶端只知道傳入工廠類的參數，對於如何創建對象不關心：客戶端既不需要關心創建細節，甚至連類名都不需要記住，只需要知道類型所對應的參數。