[.NET]重構之路系列v12 –用 Decorator Pattern 讓職責分離與組合

2012-07-16

9866
0
重構之路系列
2012-07-17

前言

在 legacy 系統中，總是可以看到職責混淆不清，疊床架屋的物件設計。或是為了重用程式碼，把繼承鏈搞的落落長，導致因為繼承關係而產生強耦合的情況，無法因應需求來變更設計。

這篇文章要介紹的，就是將職責混和的情況分開，讓每個職責的程式碼只有一份，因應需求，透過工廠，來將物件組合起來，達到需求所需要的功能。

原本的程式碼

之前在準備物件導向 training 的 homework 題目時，剛好在噗浪與小朱討論到什麼樣的題目適合讓學員練習。最後，決定設計一個「幫DAO穿衣服」的題目。

下面這段程式碼，就是重構前的程式碼，題目的需求如同 class 上的註解所描述，接著我們針對重構的需求，以及可能面臨到的需求異動，來進行設計。

    /// <summary>
    /// 原本需求：
    /// Product資料異動時，需記錄log，查詢不用
    /// 對Product進行CRUD時，需檢查權限
    /// 
    /// 重構需求：
    /// 1.
    /// 將權限驗證與log，從ProductDao獨立出來
    /// 讓ProductDao只處理CRUD的需求
    /// 
    /// 需求異動：
    /// 1.
    /// 在測試環境時，不檢查權限與不記錄log。
    /// 檢查測試環境條件，請使用Context.IsTestEnvironment
    ///     
    /// </summary>
    public class ProductDao
    {
        private Log _log = new Log();

        public string Message { get; private set; }

        public void Delete(string id)
        {
            //驗證使用者是否有權限，對此商品ID進行刪除動作
            ProductAuthorizationService auth = new ProductAuthorizationService() { ProductId = id, AccessType = AccessType.Delete };
            var isValid = auth.Check();

            if (isValid)
            {
                //模擬實際刪除資料                
                Console.WriteLine("刪除商品ID為{0}的資料", id);
                this.Message = "刪除成功";
            }
            else
            {
                this.Message = "權限不符，刪除失敗";
            }

            this._log.Write(this.Message);
        }


        public void Create(Entity.Product product)
        {
            //驗證使用者是否有權限，對此商品ID進行新增動作
            ProductAuthorizationService auth = new ProductAuthorizationService() { Supplier = product.Supplier, AccessType = AccessType.Insert };
            var isValid = auth.Check();

            if (isValid)
            {
                //模擬實際新增資料
                Console.WriteLine("新增商品ID為{0}, Name為{1}, Supplier為{2} 的資料", product.Id, product.Name, product.Supplier);
                this.Message = "新增成功";
            }
            else
            {
                this.Message = "權限不符，新增失敗";
            }

            this._log.Write(this.Message);
        }

        public Entity.Product Query(string id)
        {
            ProductAuthorizationService auth = new ProductAuthorizationService() { ProductId = id, AccessType = AccessType.Query };

            var isValid = auth.Check();

            if (isValid)
            {
                //模擬查詢資料
                var result = new Product() { Id = id, Name = "測試Name", Supplier = "測試Supplier" };

                this.Message = "查詢成功";
                return result;
            }
            else
            {
                this.Message = "權限不符，查詢失敗";
                return null;
            }

        }
    }

原本的Class Diagram

從 class diagram 可以看到，每一個 class 的關係，都是直接相依。而且 ProductDao 的職責除了原本的 CRUD 以外，還與 Log 以及權限驗證模組相耦合。

重構後的Class Diagram

Class diagram 重點（用紅色箭頭標記的就是重要的關係）：

相依於介面。
實際進行 CRUD 的動作，仍在 ProductDao 中，但就只有 CRUD 的動作。
ProductDao, LogProductDao, AuthrizeProductDao 三個 class 都實作 IProductDao，也就代表著，三個 class 對外都擁有 IProductDao 的行為。
LogProductDao 以及 AuthrizeProductDao，與 IProductDao 除了實作的關係以外，還有聚合的關係。簡單地說，這兩個物件身上，還放著一個 IProductDao 的物件。

圖上忽略的兩個部分：

工廠，仍需要工廠類別，只是不在 class diagram 上標記出相關關係，以簡化與關注重點。
Program 直接相依於 Product，以介面導向來說，中間是要隔一層介面。但為了關注在作業重點上，而將其他部分簡化。

重構的目的

在 Product Entity 中，Product應該只會看的到一個 IProductDao，而且只關注於 IProductDao 介面上所提供的行為。Product Entity 的行為會很乾淨，與對外物件互動的關係也會很乾淨。
讓 ProductDao只負責處理 CRUD，LogDao 則只負責加上 log，AuthDao 則只關注在權限驗證。將物件職責分乾淨，同樣的程式碼不會散落一地與重複出現。
生成 IProductDao 的動作，以及該如何根據條件來決定組合，則交給 factory 來決定。這樣一來脆弱的 if/else 或變動的條件，就只會存在於 factory，且這樣的變動只會影響物件如何組合，而不會影響到物件內部的職責邏輯。
讓物件的相依性降到最低，內聚力拉到最高，就會有彈性，且影響範圍最低，發生需求異動或問題時，可以快速地找到對應物件進行修改，且外部對這樣的修改是無感的。