先要給各位同窗灌輸一個思想,世間本無設計模式,用的人多了,天然就有了html
沒有太明顯的優劣之分,只道是誰更適合設計模式
若是無法理解<<工廠>>,建議閱讀上一篇 設計模式 2/23 工廠模式(一) ,畢竟是一個漸進明細的過程,急不來的ide
這一篇分享 工廠模式spa
回想一下簡單工廠,咱們把具體類的實例化工做放在一個工廠方法裏面來執行.設計
同時故意在上一篇提到了開放-封閉原則.code
仔細想象看看上一篇的代碼,到底有沒有遵照這個原則,或者說這個原則有沒有被嚴格意義的遵照,或者說遵照的程度是多少。視頻
若是咱們要新增一種Email的處理,咱們須要修改的是工廠,在工廠裏面加case ,break,這個事實業務擴展了,可是代碼修改了,若是使用工廠方法,咱們能夠避免這種修改工廠的狀況htm
保持一個對擴展開發,對修改關閉的原則對象
工廠模式 定義一個建立對象的接口,讓其子類本身決定實例化哪個工廠類,工廠模式使其建立過程延遲到子類進行。blog
敲黑板的時候又來了
定義一個接口,讓子類決定實例化哪個工廠,建立過程延遲到子類進行。怎麼理解,怎麼破,怎麼辦!
想象這樣一個場景,咱們知道世界製造業霸主,富士康集團,幾乎覆蓋了全部電子產品的製造,如 手機,鼎盛時期,蘋果,摩托,諾基亞,等等,都是由其製造。
而這些製造又是由富士康旗下的子公司進行製造,好比如今叫富智康的公司,當時就是生產諾基亞,而如今的鄭州富士康,專一蘋果的生產
這個時候,咱們理解富士康就是一個接口,他高傲的告訴全世界,我能夠生產手機,個人子公司,只要實現我,就會製造手機。咱們是弱關係,咱們是聚合,個人子公司必須實現製造手機同時也能夠製造電腦!!!
因而乎,各個子公司就是富士康的子類,對每一個子公司來說,只有在子公司內部,纔會去具體生產對應的手機
當你想生產蘋果手機的時候,你來到富士康的大門,問,蘋果生產廠怎麼走,而後就獲得指引,一路聞着味尋去
重點,你,你想生產蘋果手機,不是富士康想生產蘋果手機,決定權,選擇權是在你,客戶端,而不是工廠
仔細琢磨,其中的微妙,之前是你告訴富士康你要生產蘋果手機,而後富士康去決定讓誰生產,如今是你決定讓富士康的某個廠爲你生產蘋果手機,
你-富士康-廠
你-富士康的廠
細微的差異,帶來的是無窮的煩惱
講完怎麼理解,咱們看看代碼怎麼實現。依然用咱們上一篇對應的例子,
處理不一樣類型的文件,有音頻的,視頻的,圖片的,文本的
採用工廠模式,先定義一個接口,
/// <summary> /// 處理工廠接口 /// </summary> public interface IHandleFactory { /// <summary> /// 建立具體的工廠 /// </summary> /// <returns></returns> Handle CreateHandle(); }
而後,讓其子類本身決定實例化哪個工廠類
音頻處理工廠
/// <summary> /// 音頻處理工廠 /// </summary> public class AudioHandleFactory : IHandleFactory { /// <summary> /// 我實例化 音頻處理 /// </summary> /// <returns></returns> public Handle CreateHandle() { return new AudioHandle(); } }
圖片處理工廠
/// <summary> /// 圖片處理工廠 /// </summary> public class ImageHandleFactory : IHandleFactory { /// <summary> /// 我實例化 圖片處理 /// </summary> /// <returns></returns> public Handle CreateHandle() { return new ImageHandle(); } }
文本處理工廠
/// <summary> /// 文本處理工廠 /// </summary> public class TextHandleFactory : IHandleFactory { /// <summary> /// 我實例化 文本處理 /// </summary> /// <returns></returns> public Handle CreateHandle() { return new TextHandle(); } }
而後具體的處理方法類和之前同樣
/// <summary> /// 抽象類 處理 /// </summary> public abstract class Handle { /// <summary> /// 處理文件 /// </summary> public abstract void HandleFile(); } /// <summary> /// 圖片處理類 /// </summary> public class ImageHandle : Handle { public override void HandleFile() { Console.WriteLine("我開始處理圖片文件了"); } } /// <summary> /// 文本處理類 /// </summary> public class TextHandle : Handle { public override void HandleFile() { Console.WriteLine("我開始處理文本文件了"); } } /// <summary> /// 音頻處理工廠 /// </summary> public class AudioHandleFactory : IHandleFactory { /// <summary> /// 我實例化 音頻處理 /// </summary> /// <returns></returns> public Handle CreateHandle() { return new AudioHandle(); } }
咱們看客戶端怎麼調用
static void Main() { var handleFactory=new AudioHandleFactory(); var handle = handleFactory.CreateHandle(); handle.HandleFile(); }
OK,以上就是工廠模式
不要指指點點,不要指指點點
我知道,昨天的那種狀況應該按照以下寫
static void Main() { IHandleFactory handleFactory = null; var fileType = "Image"; switch (fileType) { case "Audio": handleFactory = new AudioHandleFactory(); break; case "Image": handleFactory = new ImageHandleFactory(); break; case "Text": handleFactory = new TextHandleFactory(); break; } if (handleFactory != null) { var handle = handleFactory.CreateHandle(); handle.HandleFile(); } Console.ReadLine(); }
這樣才符合題意
我知道,仍是有case,break, 可是咱們已經把判斷提到了客戶端,仔細琢磨下,和最初的寫方法,判斷,再到後續的簡單工廠模式,但如今的工廠模式,一不一不的進化,細微的差異,程序的可擴展性,仔細回味
仍然不要急,咱們最終是會使用反射利器,幹掉switch的
總結下
優勢
一、一個調用者想建立一個對象,只要知道其名稱就能夠了。
二、高擴展性,若是想增長一個產品,只要擴展一個工廠類和一個產品類就能夠。
三、屏蔽產品的具體實現,調用者只關心產品的接口。
缺點
每次增長一個產品時,都須要增長一個具體類和對象實現工廠,使得系統中類的個數成倍增長,在必定程度上增長了系統的複雜度,同時也增長了系統具體類的依賴。
系統越作越複雜,究竟是一開始的寫方法調用直接調用方便,仍是如今工廠模式方便,實際上是根據現實業務進行選擇的
以上就是關於工廠模式的分享
一路前行,風雨無阻,不定時更新,原計劃是明天晚上更新,但明天會不家,因此提早更新