天天看點

簡單工廠方法

遇到問題直覺地利用計算機可以了解的方式去分析解決這個問題,但這種思維模式僅僅能局限與解決這個問題。

但寫的程式卻不一定easy維護,不easy擴充,更不easy複用,為了把代碼寫的易維護、易擴充、易複用,我們非常有必要學習設計模式

1.緊耦合和松耦合

利用面向對象的性質,封裝、繼承、多态

2.單一職責原則:就一個類而言,應該僅有一個引起它變化的原因

3.簡單工廠方法

簡單工廠模式的實質是由一個工廠類依據傳入的參數。動态決定應該建立哪一個産品類(這些産品類繼承自一個父類或接口)的執行個體。

 /// <summary>

    /// 運算類

    /// </summary>

    public class Operation

    {

        private double _numberA = 0;

        private double _numberB = 0;

        /// <summary>

        /// 數字A

        /// </summary>

        public double NumberA

        {

            get

            {

                return _numberA;

            }

            set

                _numberA = value;

        }

        /// 數字B

        public double NumberB

                return _numberB;

                _numberB = value;

        /// 得到運算結果

        /// <returns></returns>

        public virtual double getResult()

            double result = 0; 

            return result;

    }

    /// <summary>

    /// 加法類

    class OperationAdd : Operation

        public override double getResult()

            result = NumberA + NumberB;

    /// 減法類

    class OperationSub : Operation

       public override double getResult()

            double result = 0;

            result = NumberA - NumberB;

    /// 運算類工廠

    class OperationFactory

        public static Operation createOperate(string operate)

            Operation oper = null;

            switch (operate)

                case "+":

                    {

                        oper = new OperationAdd();

                        break;

                    }

                case "-":

                        oper = new OperationSub();

            return oper;

長處:

工廠類是整個模式的關鍵.包括了必要的邏輯推斷,依據外界給定的資訊,決定到底應該建立哪個詳細類的對象.通過使用工廠類,

外界能夠從直接建立詳細産品對象的尴尬局面擺脫出來,隻須要負責“消費”對象就能夠了。而不必管這些對象到底怎樣建立及怎樣組織的.

明白了各自的職責和權利,有利于整個軟體體系結構的優化。

缺點:

因為工廠類集中了所有執行個體的建立邏輯,違反了高内聚責任配置設定原則,将所有建立邏輯集中到了一個工廠類中;它所能建立的類僅僅能是事先考慮到的,

假設須要加入新的類,則就須要改變工廠類了。

當系統中的詳細産品類不斷增多時候,可能會出現要求工廠類依據不同條件建立不同執行個體的需求.

這樣的對條件的推斷和對詳細産品類型的推斷交錯在一起,非常難避免子產品功能的蔓延,對系統的維護和擴充非常不利。

這些缺點在工廠方法模式中得到了一定的克服。

使用場景:

工廠類負責建立的對象比較少;

客戶僅僅知道傳入工廠類的參數,對于怎樣建立對象(邏輯)不關心;

因為簡單工廠非常easy違反高内聚責任配置設定原則。是以一般僅僅在非常簡單的情況下應用。