本筆記摘抄自：https://www.cnblogs.com/PatrickLiu/p/7551373.html，記錄一下學習過程以備後續查用。
一、引言
簡單工廠模式并不屬于GoF23裡面的設計模式，其實它屬于一個過渡的模式，這個模式是為了引出下一篇要講的模式：工廠模式。
二、簡單工廠模式的介紹
無論是簡單工廠還是複雜工廠，首先它們都是工廠，工廠是幹什麼的呢？ 在現實生活中的工廠是負責生産産品的。比如我們要吃餅幹不用自己做，去超市買就好了，因為有工廠已經把餅幹生産好了。生産是工廠的任務，買來吃是我們自己的事，兩者互不幹涉，挺好。
那麼在面向對象的軟體設計中提到的工廠是什麼意思呢？既然也叫工廠，那肯定也是生産産品的，隻不過這個産品是一個對象的執行個體。在軟體設計中，工廠的概念就是指可以生産某個類型對象執行個體的一個類型。
有了工廠，如果我們要使用某個類型的執行個體，就直接告訴工廠就行了，它會提供給我們想要的執行個體對象。而具體工廠是怎麼生産的不用我們管，這樣我們也省事了，這就是解耦。在平常程式設計中，當使用”new”關鍵字建立一個對象時，該類就依賴于這個對象，是以它們之間的耦合度比較高。當需求變化時，我們就不得不去修改此類的源碼。此時我們可以運用面向對象（OOP）很重要的原則去解決這一類的問題，就是封裝變化點。既然要封裝改變點，自然也就要找到變化的代碼，然後把變化的代碼用類來封裝，這樣的一種思路也就是我們簡單工廠模式的實作方式了。
下面通過一個現實生活中的例子來引出簡單工廠模式：
生活中，假如自己在家做飯吃，除了要買菜、洗菜、燒菜外，還有煩人的洗碗、刷鍋等。而假如我們去外面吃飯的話，就完全沒有上述這些麻煩，隻需要到餐館點菜付款就可以了，其它的事全部由餐館搞定，此時餐館就充當簡單工廠的角色。
下面讓我們看看現實生活中的例子用代碼是怎樣來表現的？
2.1、自己做飯的情況
class Program
{
/// <summary>
/// 簡單工廠模式：菜抽象類
/// </summary>
public abstract class Food
{
//輸出點了什麼菜
public abstract void Print();
}
/// <summary>
/// 簡單工廠模式：蕃茄炒雞蛋
/// </summary>
public class TomatoesWithEggs : Food
{
public override void Print()
{
Console.WriteLine("一份蕃茄炒蛋。");
}
}
/// <summary>
/// 簡單工廠模式：洋芋肉絲
/// </summary>
public class PotatosWithShreddedPork : Food
{
public override void Print()
{
Console.WriteLine("一份洋芋肉絲。");
}
}
/// <summary>
/// 簡單工廠模式：自己做飯的情況
/// 沒有簡單工廠，自個兒想吃什麼菜隻能自己炒。
/// </summary>
public class Oneself
{
/// <summary>
/// 燒菜方法
/// </summary>
/// <param name="dishName">菜名</param>
/// <returns></returns>
public Food Cook(string dishName)
{
Food food = null;
if (dishName.Equals("蕃茄炒蛋"))
{
food = new TomatoesWithEggs();
}
else if (dishName.Equals("洋芋肉絲"))
{
food = new PotatosWithShreddedPork();
}
return food;
}
}
static void Main(string[] args)
{
#region 簡單工廠模式：自己做飯的情況
Oneself oneself = new Oneself();
var food = oneself.Cook("蕃茄炒蛋");
food.Print();
Console.Read();
#endregion
}
} View Code
運作結果如下：
2.2、外出就餐的情況
有了餐館（也就是簡單工廠）之後，我們就可以把這些操作交給餐館去做，此時消費者（也就是我們）對菜（也就是具體對象）的依賴關系從直接變成間接的，這樣就實作了面向對象的另一個原則——降低對象之間的耦合度。
class Program
{
/// <summary>
/// 簡單工廠模式：菜抽象類
/// </summary>
public abstract class Food
{
//輸出點了什麼菜
public abstract void Print();
}
/// <summary>
/// 簡單工廠模式：蕃茄炒雞蛋
/// </summary>
public class TomatoesWithEggs : Food
{
public override void Print()
{
Console.WriteLine("一份蕃茄炒蛋。");
}
}
/// <summary>
/// 簡單工廠模式：洋芋肉絲
/// </summary>
public class PotatosWithShreddedPork : Food
{
public override void Print()
{
Console.WriteLine("一份洋芋肉絲。");
}
}
/// <summary>
/// 簡單工廠模式：簡單工廠類，負責燒菜。
/// </summary>
public static class FoodSimpleFactory
{
public static Food CreateFood(string dishName)
{
Food food = null;
if (dishName.Equals("洋芋肉絲"))
{
food = new PotatosWithShreddedPork();
}
else if (dishName.Equals("蕃茄炒蛋"))
{
food = new TomatoesWithEggs();
}
return food;
}
}
static void Main(string[] args)
{
#region 簡單工廠模式：外出就餐的情況
//顧客充當用戶端，負責調用簡單工廠來生産對象。即客戶點菜，廚師（相當于簡單工廠）負責燒菜(生産的對象)。
//客戶點一份蕃茄炒蛋
Food food1 = FoodSimpleFactory.CreateFood("蕃茄炒蛋");
food1.Print();
//客戶點一份洋芋肉絲
Food food2 = FoodSimpleFactory.CreateFood("洋芋肉絲");
food2.Print();
Console.Read();
#endregion
}
} 簡單工廠模式在很多時候可以叫做靜态工廠模式（因為工廠類都定義了一個靜态方法），由一個工廠類根據傳入的參數決定建立出哪一種産品類的執行個體（通俗點表達：通過客戶下的訂單來負責燒那道菜）。
三、優點與缺點
看完簡單工廠模式的實作之後，很多人肯定會有這樣的疑惑--我們隻是把變化的代碼移到了工廠類中罷了，好像沒有其它的變化了。如果客戶想吃其它菜時，此時我們還是需要修改工廠類中的方法，也就是多加case語句（沒應用簡單工廠模式之前，修改的是客戶類）。我首先要說：大家想的很對，每種設計模式隻會解決一種問題，它們有自己的使用場景，沒有一種模式可以解決所有問題，這個就是簡單工廠模式的缺點所在（這個缺點後面介紹的工廠方法模式可以很好地解決）。
3.1、簡單工廠模式的優點
1）簡單工廠模式解決了用戶端直接依賴于具體對象的問題。用戶端可以消除直接建立對象的責任，而僅僅是消費産品。
2）簡單工廠模式實作了對責任的分割，也起到了代碼複用的作用，因為之前的實作（自己做飯的情況）中，換了一個人同樣要去在自己的類中實作做菜的方法，然後有了簡單工廠之後，去餐館吃飯的所有人都不用那麼麻煩了，隻需要負責消費就可以了，此時簡單工廠的燒菜方法就讓所有客戶共用了。
3.2、簡單工廠模式的缺點
1）工廠類集中了所有産品建立邏輯，一旦不能正常工作，整個系統都會受到影響（通俗地意思就是：一旦餐館沒飯或者關門了，很多不願意做飯的人就沒飯吃了）。
2）系統擴充困難，一旦添加新産品就不得不修改工廠邏輯，這樣就會造成工廠邏輯過于複雜。
3.3、簡單工廠的使用場景
1）當工廠類負責建立的對象比較少時可以考慮使用簡單工廠模式。
2）客戶如果隻知道傳入工廠類的參數，對于如何建立對象的邏輯不關心時可以考慮使用簡單工廠模式。
四、.NET中簡單工廠模式的實作
.NET中System.Text.Encoding類就實作了簡單工廠模式，該類中的GetEncoding(int codepage)就是工廠方法，具體的代碼可以通過Reflector反編譯工具進行檢視。
.NET中Encoding的UML圖為：
Encoding類中實作的簡單工廠模式是簡單工廠模式的一種演變，此時簡單工廠類由抽象産品角色扮演，然而.NET中Encoding類是如何解決簡單工廠模式中存在的問題的呢（即如果新添加一種編碼怎麼辦）？在GetEncoding方法裡的switch函數有如下代碼：
switch (codepage)
{
.......
default:
unicode = GetEncodingCodePage(codepage);
if (unicode == null)
{
unicode = GetEncodingRare(codepage); //當編碼很少見時
}
break;
......
} 在GetEncodingRare方法裡有一些不常用編碼的執行個體化代碼，微軟正式通過這個方法來解決新增加一種編碼的問題。（其實也就是列出所有可能的編碼情況），微軟之是以以這樣的方式來解決這個問題，可能是由于現在編碼已經穩定了，添加新編碼的可能性比較低，是以在.NET 4.5仍然未改動這部分代碼。
五、總結
說起簡單工廠，其實是一個很容易的工廠，可能很多人可能有意或者無意的使用過模式。模式不要太關注實作細節，要關注模式得出的原因及分析問題的方法。我們一定要好好的記住面向對象的設計原則，然後好好的體會模式之美，了解就會更多一些。