[設計模式整理筆記 一] 基礎知識

[導讀]

[設計模式整理筆記 一] 基礎知識

[設計模式整理筆記 二] 簡單原廠模式（Simple Factory)

[設計模式整理筆記 三] 原廠模式（Factory)

[設計模式整理筆記 四] 抽象原廠模式（Abstract Factory)

[設計模式整理筆記 五] 建立者模式（Builder)

[設計模式整理筆記 六] 原廠模式與建立者模式總結

[設計模式整理筆記 七] 原型模式(ProtoType)

[設計模式整理筆記 八] 單例模式(Singleton)

[設計模式整理筆記 九] 面板模式(Facade)

....後續， 包括部分例子

[/導讀]

 

設計模式的範圍極廣， 我最近也是略來整理與研究了一下， 感覺每一段時間整理一下自己學到的東西， 會發現得到的知識會比以前學的更多更全面， 不然都是散散的在腦袋裡面。下面例子是一個大型企業的計算工資模式， 因為有很多各地的子公司， 當然計算工資的方法也是不同的。

先定義一個介面， 確定計算工資的方法， 如下：

using System;

namespace ConsoleApp
{
    public interface ISalary
    {
        void CommandSalary();
    }
}

 

下面各地不同的子公司分別繼承這個介面的CommandSalary方法，下面是深圳與北京二個地方的計算方法。設計二個類如下：

代碼

using System;

namespace ConsoleApp
{
    public class ShenZhenSalary : ISalary
    {
        public void CommandSalary()
        {
            Console.WriteLine("這是深圳子公司的工資計算模組");
        }
    }
}

 

 北京子公司

代碼

using System;

namespace ConsoleApp
{
    public class BeiJinSalary : ISalary
    {
        public void CommandSalary()
        {
            Console.WriteLine("這是北京子公司的工資計算模組");
        }
    }
}

 

到裡面基本類已經設計完成， 好多人都會在代碼中要用到時候new一個出來，這樣的代碼可能會造成難以維護， 給人好亂的感覺。 或像下面的代碼那樣調用，代碼如下：

代碼

using System;

namespace ConsoleApp
{
    class Program
    {
        public static void Main(string[] args)
        {
            ISalary Salary = CreateSalary("BeiJin");  //需要調用子公司的工資計算過程時, 把子公司的名稱傳進去
            Salary.CommandSalary();
            Console.ReadLine();
        }

        /// <summary>
        /// 通過傳進的公司名返回相應的執行個體
        /// </summary>
        /// <param name="CompanyName">子公司的名稱</param>
        /// <returns></returns>
        private static ISalary CreateSalary(string CompanyName)
        {
            ISalary Salary = null;
            if (CompanyName == "ShenZhen")  //這裡可以通過更多方法來判斷,通過不同的名返回相應的執行個體
            {
                Salary = new ShenZhenSalary();
            }
            else if (CompanyName == "BeiJin")
            {
                Salary = new BeiJinSalary();
            }
            return Salary;
        }
    }
}

 

這樣就可以調用計算得到各子公司的工資， 對於小型的公司， 這樣的設計已經是相當的完美了， 但對於一個大公司， 子公司可能有幾十個更甚至幾百個， 這樣在CreateSalary中就需要更多的if來判斷了， 這顯然對維護是極為不好的， 那需要怎樣設計呢？ 這就是所要討論到的設計模式了， 下面接著的文章就會是常用的原廠模式來編寫這個模組。

注:這是一個新手常用的寫法，這還沒講到原廠模式，這裡只是說這樣寫的類不好，不符合系統的設計模式， 先舉個反例， 後面將會介紹設計模式。有些朋友沒看清楚， 標註一下。

 

（註：這是個人學習過程的心得，可能存在極大的錯誤，請大家指正）