【設計模式】簡單工廠模式 Simple Factory Pattern

簡單工廠模式Simple Factory Pattern【Simple Factory Pattern】是設計模式裏最簡單的一個模式,又叫靜態工廠模式【Static Factory Pattern】,這個模式沒有收錄在GOF 23 個模式中,由於他很是簡單,在項目中使用也很是普遍,因此就用它來開篇。html

1、簡單工廠模式定義:

簡單工廠模式(Simple Factory Pattern):定義一個工廠類,它能夠根據參數的不一樣返回不一樣類的實例,被建立的實例一般都具備共同的父類。由於在簡單工廠模式中用於建立實例的方法是靜態(static)方法,所以簡單工廠模式又被稱爲靜態工廠方法(Static Factory Method)模式,它屬於類建立型模式。設計模式

2、簡單工廠模式結構圖

image

簡單工廠結構圖學習

從簡單工廠結構圖中咱們能夠看出它包含三個角色:測試

1. IProduct (抽象產品角色):

它是工廠類所建立的全部對象的父類,封裝了各類產品對象的公有方法,它的引入將提升系統的靈活性,使得在工廠類中只需定義一個通用的工廠方法,由於全部建立的具體產品對象都是其子類對象。抽象產品可使用接口和抽象類來來實現。編碼

2. ConcreteProduct (具體產品角色):

它是簡單工廠模式的建立目標,全部被建立的對象都充當這個角色的某個具體類的實例。每個具體產品角色都繼承了抽象產品角色,須要實如今抽象產品中聲明的抽象方法。在簡單工廠模式中,客戶端經過工廠類來建立一個產品類的實例,而無須直接使用new關鍵字來建立對象,它是工廠模式家族中最簡單的一員。 在使用簡單工廠模式時,首先須要對產品類進行重構,不能設計一個一應俱全的產品類,而需根據實際狀況設計一個產品層次結構,將全部產品類公共的代碼移至抽象產品類,並在抽象產品類中聲明一些抽象方法,以供不一樣的具體產品類來實現。spa

3. Factory (工廠角色):

這個角色就是工廠類,他是工廠模式的核心,負責實現建立全部產品實例的內部邏輯;工廠類能夠被外界直接調用,建立所需的產品對象;在工廠類中提供了靜態的工廠方法factoryMethod(),它的返回類型爲抽象產品類型Product。設計

3、簡單工廠的代碼實現

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;
    }
}

客戶端調用:code

static void Main()
{
    var product = Factory.Create("A");
    product.SomeMethod();

    product = Factory.Create("B");
    product.SomeMethod();

    Console.ReadKey();
}

輸出結果:htm

image

 

4、需求改變促使代碼重構獲得簡單工廠模式

甲方提出了這樣一個需求:要求作一個音頻播放器。只須要支持播放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();
    }
}

輸出結果以下:

image

甲方看到軟件試用一翻感受不錯很滿意,趕忙給開發人員支付了開發費用。將軟件投放市場。

很長一段時間,市場放映不錯,這個音頻播放器市場佔有率提升很快。可是有一天一種新的音頻格式誕生了,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();
    }
}

運行軟件如圖:

image

甲方拿到軟件測試一翻,很滿意,趕忙投入市場,反響強烈,市場佔有率進一步提升。

隨着時間的推移一種新的音樂格式出現了,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();
    }
}

輸出結果:

image

好了這個音頻播放器支持mp3了, 甲方很是高興,趕忙把這個新的版本投入市場。甲方經過此次升級挽回了一些他在音頻播放市場上的一些頹勢。

經過這麼一次忽然的襲擊使開發人員收穫很多,最起碼學到了一種設計模式(simple facfory)的使用,也是成就滿滿。 可是開發人員仍是心有餘悸,若是哪一天忽然有出來個什麼新的格式是否是又要加班加點的搞上一陣子。 他想若是在不改變這個軟件已有代碼的狀況下,來擴展,比方說,新增了一個類型,可是不須要修改代碼經過寫一個類或者增長一些配置就能夠實現這個完美支持新的格式的音頻文件?(這不是OCP原則嗎? ) 那麼這個問題Simple Factory Pattern 能作到嗎? 問題先留着,隨着模式學習的深刻, 讓咱們慢慢在後面的學習中去尋找答案。

5、簡單工廠模式的優勢

  1. 工廠類含有必要的判斷邏輯,能夠決定在何時建立哪個產品類的實例,客戶端能夠免除直接建立產品對象的責任,客戶程序不須要產品的具體生產細節;簡單工廠模式經過這種作法實現了對責任的分割,它提供了專門的工廠類用於建立對象。
  2. 客戶端無須知道所建立的具體產品類的類名,只須要知道具體產品類所對應的參數便可,不須要知道產品是怎麼建立的。
  3. 經過引入配置文件,能夠在不修改任何客戶端代碼的狀況下更換和增長新的具體產品類,在必定程度上提升了系統的靈活性。
  4. 簡單工廠將建立產品的職責放在了單獨的靜態工廠中去處理和維護必定長度上體現了SRP原則

6、簡單工廠模式的缺點

  1. 因爲工廠類集中了全部產品建立邏輯,一旦不能正常工做,整個系統都要受到影響。
  2. 使用簡單工廠模式將會增長系統中具體產品類的個數,在必定程序上增長了系統的複雜度和理解難度。
  3. 系統擴展困難,一旦添加新產品就不得不修改工廠邏輯,在產品類型較多時,有可能形成工廠邏輯過於複雜,不利於系統的擴展和維護。
  4. 因爲在增長新的產品的時候簡單工廠模式必需要修改靜態的工廠方法,因此它違背了OCP原則

7、工廠模式的使用場景

在如下狀況下可使用簡單工廠模式:

  1. 工廠類負責建立的對象比較少:因爲建立的對象較少,不會形成工廠方法中的業務邏輯太過複雜。
  2. 客戶端只知道傳入工廠類的參數,對於如何建立對象不關心:客戶端既不須要關心建立細節,甚至連類名都不須要記住,只須要知道類型所對應的參數。
相關文章
相關標籤/搜索