本筆記摘抄自: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 } }View Code
運行結果如下:

簡單工廠模式在很多時候可以叫做靜態工廠模式(因為工廠類都定義了一個靜態方法),由一個工廠類根據傳入的引數決定創建出哪一種產品類的實體
(通俗點表達:通過客戶下的訂單來負責燒那道菜),
三、優點與缺點
看完簡單工廠模式的實作之后,很多人肯定會有這樣的疑惑--我們只是把變化的代碼移到了工廠類中罷了,好像沒有其它的變化了,如果客戶想吃其它
菜時,此時我們還是需要修改工廠類中的方法,也就是多加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仍然未改動這部分代碼,
五、總結
說起簡單工廠,其實是一個很容易的工廠,可能很多人可能有意或者無意的使用過模式,模式不要太關注實作細節,要關注模式得出的原因及分析問題的
方法,我們一定要好好的記住面向物件的設計原則,然后好好的體會模式之美,理解就會更多一些,
轉載請註明出處,本文鏈接:https://www.uj5u.com/net/82992.html
標籤:C#
下一篇:Reflection(反射)
