Unity【話大】設計模式之工廠方法

前言：筆者在最開始寫程式的時候經常會遇到一種情況，例如更改一個字段、或者添加一種小功能，就要把原來寫過的東西幾乎廢棄掉，或者更改大量以前寫過的代碼。又或者自己寫的東西時間久了再去回顧，完全找不到到時為什麼這麼寫的頭緒，如果遇到了Bug更是無法快速定位在哪裡小範圍出現的問題。如果你也經常遇到這種問題，就說明你現階段非常需要學習下設計模式了。

在網上經常說的設計模式有23種，也有一些更多的設計模式，無非也是從這些設計模式中變種而來。如果讓筆者來形容什麼是設計模式，我認為設計模式是：一種思想，一種模式，一種套路，一種解決問題的高效政策。

舉個生活中的列子：你需要從家去公園，雖然都是從A點到B點，但目的是着急取東西，你會用代步工具快速到達，但如果僅僅是打發時間，完全可以散步去。用代步工具和散步本身沒有絕對的對錯，隻是根據當時的需求采取的政策。設計模式這種思想，就是根據你當時的需求給你提供最高效的政策。

有說的不正确或者不準确的地方歡迎留言指正

有什麼有趣的寫作技巧或者想法歡迎大家給我留言，大家的幫助是我寫下去最有效的動力

在上次的 【話大】設計模式之簡單工廠 筆者有提到過還有跟多優化的地方，下面筆者跟大家聊一聊簡單工程的優化版 ------【工廠方法】

現在我們的策劃大佬來了新的需求，說海瀾我們現在需要增加“産品”，原來的“産品”不好，全部去掉，換成10個新的，而且每個“産品”在生産之前要有一些檢測機制。按照簡單工廠的套路，我們知道，在工廠類Switch中把原來的産品的case删掉，然後添加10個新的case，然後在對應的語句塊中添加需要的檢測機制。 設計模式之面向對象七大原則 我們知道，這種方式違背了單一原則和開閉原則，違背單一原則是因為過多的涉及其他産品的生産，雖然都是生産産品。違背開閉原則是因為，在一個工廠類中有許多産品的産生，不管是增加産品或者是對單一産品的修改都有可能造成其他産品的幹擾。是以我要對他們進行再次的分離，再次的封裝。

public interface IProduct{}

public class Computer : IProduct{}

public class IPhone : IProduct{}

public class Mac : IProduct{}

public class IPad : IProduct{}
           

public interface IFactory
{
    IProduct CreatProduct();
}

public class FactoryComputer : IFactory
{
    public virtual IProduct CreatProduct()
    {
        return default(Computer);
    }
}

public class FactoryIPhone : IFactory
{
    public virtual IProduct CreatProduct()
    {
        return default(IPhone);
    }
}

public class FactoryMac : IFactory
{
    public virtual IProduct CreatProduct()
    {
        return default(Mac);
    }
}

public class FactoryIPad : IFactory
{
    public virtual IProduct CreatProduct()
    {
        return default(IPad);
    }
}
           

最終使用的時候變成了這個樣子

public void ExampleFactoryMethod()
    {
        IFactory factory = new FactoryComputer();
        IProduct computer = factory.CreatProduct();

        factory = new FactoryIPhone();
        IProduct iPhone = factory.CreatProduct();

        factory = new FactoryMac();
        IProduct mac = factory.CreatProduct();

        factory = new FactoryIPad();
        IProduct iPad = factory.CreatProduct();
    }
           

現在讓我們和簡單工廠對比一下

現在直覺的看，代碼量增加了，而且對産品的選擇由下端工廠類又轉交給上端業務邏輯層了。但筆者認為對于版本疊代來說，這種犧牲是值得的，理由有一下幾點

• 産品的增加和删除不會影響到其他産品的産出
• 單個産品邏輯修改隻需要在對應的工廠類修改即可
• 職責更加明确，友善後續的維護和Bug定位
• 更符合開閉原則

為什麼說更符合開閉原則呢？因為如果在在版本疊代的時候，在原有産品的基礎上添加檢測等機制，可以用如下寫法，完全不會涉及到原來類的源碼。

public class FactoryIPad : IFactory
{
    public virtual IProduct CreatProduct()
    {
        return default(IPad);
    }
}


public class FactoryIPad_Extend : FactoryIPad
{
    public override IProduct CreatProduct()
    {
        /*
         * 檢測一
         * 檢測二
         * 檢測三
         */
        return base.CreatProduct();
    }
}
           

工廠方法(Factory Method),定義了一個用于建立對象的接口，讓子類決定執行個體化哪一個類。工廠方法使一個類的執行個體化延遲到其子類。

筆者說過，運用哪種設計模式沒有絕對的對錯，設計模式是：一種思想，一種模式，一種套路，一種解決問題的高效政策，如果真的後續不會有什麼改動，那就怎麼簡單怎麼寫就好了。當然工廠還有另一種寫法，那就是【抽象工廠】，筆者後續會提到~