定義

簡單工廠模式(Simple Factory Pattern)：又稱為靜態工廠方法(Static Factory Method)模式，它屬於類建立型模式，但不屬於23種GOF設計模式之一，說它是一種程式設計習慣可能更恰當些。在簡單工廠模式中，可以根據引數的不同返回不同類的例項。簡單工廠模式專門定義一個類來負責建立其他類的例項，被建立的例項通常都具有共同的父類。

分析

將物件的建立和物件本身業務處理分離可以降低系統的耦合度，使得兩者修改起來都相對容易。 在呼叫工廠類的工廠方法時，由於工廠方法是靜態方法，使用起來很方便，可通過類名直接呼叫，而且只需要傳入一個簡單的引數即可，在實際開發中，還可以在呼叫時將所傳入的引數儲存在

包含的角色和職責

工廠（Creator）角色：簡單工廠模式的核心，它負責實現建立所有例項的內部邏輯。工廠類的建立產品類的方法可以被外界直接呼叫，建立所需的產品物件。

抽象產品（Product）角色：簡單工廠模式所建立的所有物件的父類，它負責描述所有例項所共有的公共介面。 

具體產品（Concrete Product）角色：是簡單工廠模式的建立目標，所有建立的物件都是充當這個角色的某個具體類的例項。

程式碼例項

用面向物件的思想編寫一個簡單計算器。

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

namespace ConsoleApplication6
{

    // 抽象產品角色product
    public class Operation
    {
        private double _numberA = 0;
        private double _numberB = 0;

        public double numberA
        {
            get { return _numberA; }
            set { _numberA = value; }
        }

        public double numberB
        {
            get { return _numberB; }
            set { _numberB = value; }
        }

        public virtual double GetResult()
        {
            double result = 0;
            return result;
        }
    }

    // 具體產品角色 Concrete Product
    class OperationAdd : Operation
    {
        public override double GetResult()
        {
            double result = 0;
            result = numberA + numberB;
            return result;
        }
    }
    class OperationSub : Operation
    {
        public override double GetResult()
        {
            double result = 0;
            result = numberA - numberB;
            return result;
        }
    }
    class OperationMul : Operation
    {
        public override double GetResult()
        {
            double result = 0;
            result = numberA * numberB;
            return result;
        }
    }
    class OperationDiv : Operation
    {
        public override double GetResult()
        {
            double result = 0;
            if (numberB == 0)
                throw new Exception("除數不能為0.");
            result = numberA / numberB;
            return result;
        }
    }

    // 工廠角色 Creator
    public class OperationFactory
    {
        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;
        }
    }

    class Program
    {
        static void Main()
        {
            Operation oper;
            Console.WriteLine("請輸入要進行的運算");
            oper = OperationFactory.createOperation(Console.ReadLine());
            Console.WriteLine("請輸入第一個數字");
            oper.numberA = Convert.ToDouble(Console.ReadLine());
            Console.WriteLine("請輸入第二個數字");
            oper.numberB = Convert.ToDouble(Console.ReadLine());
            double result = oper.GetResult();
            Console.WriteLine("結果為：{0}", result);
            Console.ReadLine();
        }
    }
}
 

優缺點與使用場景

優點：工廠類是整個模式的關鍵.包含了必要的邏輯判斷,根據外界給定的資訊,決定究竟應該建立哪個具體類的物件.通過使用工廠類,外界可以從直接建立具體產品物件的尷尬局面擺脫出來,僅僅需要負責“消費”物件就可以了。而不必管這些物件究竟如何建立及如何組織的．明確了各自的職責和權利，有利於整個軟體體系結構的優化。

缺點：由於工廠類集中了所有例項的建立邏輯，違反了高內聚責任分配原則，將全部建立邏輯集中到了一個工廠類中；它所能建立的類只能是事先考慮到的，如果需要新增新的類，則就需要改變工廠類了。當系統中的具體產品類不斷增多時候，可能會出現要求工廠類根據不同條件建立不同例項的需求．這種對條件的判斷和對具體產品型別的判斷交錯在一起，很難避免模組功能的蔓延，對系統的維護和擴充套件非常不利；這些缺點在工廠方法模式中得到了一定的克服。

使用場景：工廠類負責建立的物件比較少；客戶只知道傳入工廠類的引數，對於如何建立物件（邏輯）不關心；由於簡單工廠很容易違反高內聚責任分配原則，因此一般只在很簡單的情況下應用。