簡單工廠模式

咱們先來看看一個簡單的計算機案例(一個控制檯應用程序)：

Operation是一個運算類，加減乘除方法繼承於Operation。

 

 /// <summary>
/// 運算類
/// </summary>
abstract public class Operation
{
    public double NumberA { get; set; }

    public double NumberB { get; set; }

    public abstract double GetResult();
}

 

/// <summary>
/// 加法類
/// </summary>
public class OperationAdd:Operation
{
    public override double GetResult()
    {
        return base.NumberA + base.NumberB;
    }
}

 

減法，乘法，除法類似，在此不列出。

 

在這裏就有一個問題了，我們怎麼讓程序知道我們到底是要執行哪一種運算呢？也就是如何去實例化對象的問題。

在這裏到底要實例化誰，將來會不會增加這實例化的對象，比如增加開根運算，這是很容易變化的地方，

應該考慮用一個單獨的類做這個創造實例的過程，這就是工廠。下面我們就引入簡單工廠：

public class OperationFaction
    {
        public static Operation createOperation(string operate)
        {
            Operation oper = null;
            switch (operate)
            {
                case "+":
                    oper = new OperationAdd();
                    break;
                case "-":
                    oper = new OperationSub();
                    break;
                case "*":
                    oper = new OperationMul();
                    break;
                case "/":
                    oper = new OperationDiv();
                    break;
            }
            return oper;
        }
    }

工廠方法通常是一個靜態方法，因此又叫靜態工廠方法模式，這個方法返回的類型爲通用的父類類型，但是new的是具體的子類類型。

在這裏我們只需要輸入運算符號，工廠就實例化出合適的對象，通過多態，返回的父類的方式實現了計算器的計算。

 

客戶端代碼：

class Program
    {
        static void Main(string[] args)
        {
            Operation oper = null;
            oper = OperationFaction.createOperation("+");
            oper.NumberA = 10;
            oper.NumberB = 12;
            double result = oper.GetResult();
            Console.WriteLine("運行結果爲："+result);
        }
    }

當我們需要增加各種運算，比如平方根，立方根等的時候，我們只需要添加相應的運算子類，和在工廠類中添加一個分支就可以了。

 

我們再來看看總體的UML圖：

下面我們再來詳細的分析一下簡單工廠：

優點：

簡單工廠中“工廠類”是整個模式的關鍵，包含了必要的邏輯判斷,根據外界給定的信息,決定究竟應該創建哪個具體類的對象.

通過使用工廠類,外界可以從直接創建具體產品對象的尷尬局面擺脫出來,僅僅需要負責“消費”對象就可以了。

而不必管這些對象究竟如何創建及如何組織的．明確了各自的職責和權利，有利於整個軟件體系結構的優化。

缺點：

簡單工廠不符合開放-封閉原則，簡單工廠在對每一次擴展時都要更改工廠類，這就是對修改開放了,這就不符合開閉原則。

當系統中的具體產品類不斷增多時候，可能會出現要求工廠類根據不同條件創建不同實例的需求．

這種對條件的判斷和對具體產品類型的判斷交錯在一起，很難避免模塊功能的蔓延，對系統的維護和擴展也非常不利；

工廠類集中了所有實例的創建邏輯，違反了高內聚責任分配原則，將全部創建邏輯集中到了一個工廠類中，這樣對於維護非常不方便。

簡單工廠應用場景：

工廠類負責創建的對象比較少；

客戶只知道傳入工廠類的參數，對於如何創建對象（邏輯）不關心；

由於簡單工廠很容易違反高內聚責任分配原則，因此一般只在很簡單的情況下應用。

以上內容轉自：http://blog.csdn.net/shiyuan17/article/details/9047917