C#設計模式——簡單說(簡單工廠模式)


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace 簡單的工廠模式
{
    //我們是一個食品生產工廠,都是生成吃的
    class Program
    {
        static void Main(string[] args)
        {
           var doxing=   CreateFoodFactory.Cook("雪餅");
           doxing.PrintFood();
           var doxing2=  CreateFoodFactory.Cook("酸奶");
           doxing2.PrintFood();
        }
    }
 
//生產工廠
public class CreateFoodFactory { public static Food Cook(string type) { Food food = null; switch (type) { case "雪餅": food = new 雪餅(); break; case "酸奶": food = new 酸奶(); break; } return food; } }
//生成食品的抽象類
public abstract class Food { public abstract void PrintFood(); }
//生產食物
public class 雪餅 : Food { public override void PrintFood() { Console.WriteLine("雪餅,雪餅……"); } } public class 酸奶 : Food { public override void PrintFood() { Console.WriteLine("酸奶,酸奶……"); } } }

以上的代碼很簡單吧,基本都能夠理解吧。

優點與缺點

看完簡單工廠模式的實現之后,你和你的小伙伴們肯定會有這樣的疑惑(因為我學習的時候也有)——這樣我們只是把變化移到了工廠類中罷了,好像沒有變化的問題,因為如果客戶想吃其他菜時,此時我們還是需要修改工廠類中的方法(也就是多加case語句,沒應用簡單工廠模式之前,修改的是客戶類)。我首先要說:你和你的小伙伴很對,這個就是簡單工廠模式的缺點所在(這個缺點后面介紹的工廠方法可以很好地解決),然而,簡單工廠模式與之前的實現也有它的優點:

  • 簡單工廠模式解決了客戶端直接依賴於具體對象的問題,客戶端可以消除直接創建對象的責任,而僅僅是消費產品。簡單工廠模式實現了對責任的分割。
  • 簡單工廠模式也起到了代碼復用的作用,因為之前的實現(自己做飯的情況)中,換了一個人同樣要去在自己的類中實現做菜的方法,然后有了簡單工廠之后,去餐館吃飯的所有人都不用那么麻煩了,只需要負責消費就可以了。此時簡單工廠的燒菜方法就讓所有客戶共用了。(同時這點也是簡單工廠方法的缺點——因為工廠類集中了所有產品創建邏輯,一旦不能正常工作,整個系統都會受到影響,也沒什么不好理解的,就如事物都有兩面性一樣道理

雖然上面已經介紹了簡單工廠模式的缺點,下面還是總結下簡單工廠模式的缺點:

  • 工廠類集中了所有產品創建邏輯,一旦不能正常工作,整個系統都會受到影響(通俗地意思就是:一旦餐館沒飯或者關門了,很多不願意做飯的人就沒飯吃了)
  • 系統擴展困難,一旦添加新產品就不得不修改工廠邏輯,這樣就會造成工廠邏輯過於復雜。

了解了簡單工廠模式之后的優缺點之后,我們之后就可以知道簡單工廠的應用場景了:

  • 當工廠類負責創建的對象比較少時可以考慮使用簡單工廠模式()
  • 客戶如果只知道傳入工廠類的參數,對於如何創建對象的邏輯不關心時可以考慮使用簡單工廠模式

 

然后還有什么工廠方法,抽象工廠方法。其實也都是演變下而已。把工廠抽象下。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM