C#設計模式學習筆記：(8)裝飾模式

本筆記摘抄自：https://www.cnblogs.com/PatrickLiu/p/7723225.html，記錄一下學習過程以備後續查用。一、引言今天我們要講結構型設計模式的第三個模式--裝飾模式。當第一次看到這個名稱時想到的是另外一個詞語“裝修”，個人觀點談談對“裝修”的理解吧，請大家 ...

本筆記摘抄自：https://www.cnblogs.com/PatrickLiu/p/7723225.html，記錄一下學習過程以備後續查用。

一、引言

今天我們要講結構型設計模式的第三個模式--裝飾模式。當第一次看到這個名稱時想到的是另外一個詞語“裝修”，個人觀點談談對“裝修”的理解吧，請大家

看清楚現在說是“裝修”而不是“裝飾”。當我們長大了就要準備結婚（男大當婚女大當嫁嘛），而結婚往往涉及到要買房的事。如果買的是毛坯房，假如想要房

子的內飾是大理石風格的，我們只需在毛坯房的基礎之上用大理石風格的材料裝修就可以（不需要重新蓋房）。房子裝修好了住了進來很開心，過了段時間，

發現房子在冬季比較冷，於是就想給房子增加保暖的功能，此時我們只需在房子裡面增加採暖系統（南方人使用變頻空調）。又過了一段時間，總是有陌生

人光顧，於是想給房子增加安防設備，此時我們可以在門口及室內加裝監控攝像頭（或者加紅外、門磁等布控）及安裝防盜網。隨著時間的流逝，我們可能

會根據我們的需求增加相應的功能，而在此期間，我們的房子都是可以正常使用的，從這一方面來講，“裝修”和“裝飾”有類似的概念。下麵讓我們看看裝飾模

式具體是什麼吧？

二、裝飾模式介紹

裝飾模式：英文名稱--Decorator Pattern；分類--結構型。

2.1、動機（Motivate）

在房子裝修的過程中，各種功能可以相互組合，來增加房子的功用。類似的，如果我們在軟體系統中，要給某個類型或者對象增加功能，如果使用“繼承”

的方案來寫代碼，就會出現子類暴漲的情況。比如：IMarbleStyle是大理石風格的介面定義、IKeepWarm是保暖的介面定義、IHouseSecurity是房子安全的接

口定義，就三個介面來說，House是我們房子，房子要什麼功能就實現什麼介面。如果房子要的是複合功能，介面的不同組合就會有不同的結果，但是會導致

子類膨脹嚴重，隨著功能的不斷增加，會導致子類指數增長。這個問題的根源在於我們“過度地使用了繼承來擴展對象的功能”，由於繼承為類型引入靜態特質

（所謂靜態特質，就是如果想要某種功能，我們必須在編譯時就要定義這個類，這也是強類型語言的特點。靜態，就是指在編譯的時候要確定的東西；動態，

是指運行時確定的東西），使得這種擴展方式缺乏靈活性，並且隨著子類的增多（擴展功能的增多）及子類的組合（擴展功能的組合），會導致更多子類的膨

脹（多繼承）。

如何使“對象功能的擴展”能夠根據需要來動態（即運行時）地實現？同時避免“擴展功能的增多”帶來的子類膨脹問題？從而使得任何“功能擴展變化”所導致

的影響降為最低？

2.2、意圖（Intent）

動態地給一個對象增加一些額外的職責。就增加功能而言，Decorator模式比生成子類更為靈活。—— 《設計模式》GoF

2.3、結構圖（Structure）

2.4、模式的組成

在裝飾模式中的各個角色有：

1）抽象構件角色（Component）：給出一個抽象介面，以規範準備接收附加責任的對象。

2）具體構件角色（Concrete Component）：定義一個將要接收附加責任的類。

3）裝飾角色（Decorator）：持有一個構件（Component）對象的實例，並實現一個與抽象構件介面一致的介面。

4）具體裝飾角色（Concrete Decorator）：負責給構件對象添加上附加的責任。

2.5 、裝飾模式的具體實現

繼續拿房子的例子來說吧：

    class Program
    {
        /// <summary>
        /// 該抽象類就是房子抽象介面的定義，該類型就相當於是Component類型，需要裝飾的。
        /// </summary>
        public abstract class House
        {
            //房子的裝修方法--該操作相當於Component類型的Operation方法。
            public abstract void Renovation();
        }

        /// <summary>
        /// 該抽象類就是裝飾介面的定義，該類型就相當於是Decorator類型，如果需要具體的功能，可以子類化該類型。
        /// </summary>
        public abstract class DecorationStrategy : House //關鍵點之二，體現關係為Is-A，有這個關係，裝飾的類也可以繼續裝飾了。
        {
            //通過組合方式引用Decorator類型，該類型實施具體功能的增加。
            //這是關鍵點之一，包含關係，體現為Has-A。
            protected House _house;

            //通過構造器註入，初始化平臺實現。
            protected DecorationStrategy(House house)
            {
                _house = house;
            }

            //該方法就相當於Decorator類型的Operation方法。
            public override void Renovation()
            {
                if (_house != null)
                {
                    _house.Renovation();
                }
            }
        }

        /// <summary>
        /// 我的房子，相當於ConcreteComponent類型。
        /// </summary>
        public sealed class MyHouse : House
        {
            public override void Renovation()
            {
                Console.WriteLine("裝修我的房子，比如大理石風格。");
            }
        }

        /// <summary>
        /// 增加保暖功能，相當於ConcreteDecoratorA類型。
        /// </summary>
        public sealed class KeepWarmDecorator : DecorationStrategy
        {
            public KeepWarmDecorator(House house) : base(house) { }

            public override void Renovation()
            {
                //base.Renovation();
                Console.WriteLine("增加保暖功能。");
            }
        }

        /// <summary>
        /// 增加安防設備，相當於ConcreteDecoratorB類型。
        /// </summary>
        public sealed class SecurityDecorator : DecorationStrategy
        {
            public SecurityDecorator(House house) : base(house) { }

            public override void Renovation()
            {
                //base.Renovation();
                Console.WriteLine("增加安防設備。");
            }
        }

        static void Main(string[] args)
        {
            #region 裝飾模式
            //需要裝飾的房子
            House myHouse = new MyHouse();
            myHouse.Renovation();

            //增加保暖功能
            DecorationStrategy warmHouse = new KeepWarmDecorator(myHouse);
            warmHouse.Renovation();

            //如果房子既要保暖又要安防，繼續裝飾就行。
            DecorationStrategy warmAndSecurityHouse = new SecurityDecorator(warmHouse);
            warmAndSecurityHouse.Renovation();

            Console.Read();
            #endregion
        }
    }

View Code

寫了很多備註，大家好好體會一下，裡面有兩個關鍵點，仔細把握。

運行結果如下：

三、裝飾模式的實現要點

1）通過採用組合而非繼承的手法，Decorator模式實現了在運行時動態地擴展對象功能的能力，可以根據需要擴展多個功能，避免了單獨使用繼承帶來的

“靈活性差”和“多子類衍生問題”。

2）Component類在Decorator模式中充當抽象介面的角色，不應該去實現具體的行為，而且Decorator類對於Component類應該透明--換言之Component類

無需知道Decorator類，Decorator類是從外部來擴展Component類的功能。

3）Decorator類在介面上表現為Is-A Component的繼承關係，即Decorator類繼承了Component類所具有的介面，但在實現上又表現為Has-A Component

的組合關係，即Decorator類又使用了另外一個Component類。我們可以使用一個或者多個Decorator對象來“裝飾”一個Component對象，且裝飾後的對象仍然

是一個Component對象。

4）Decorator模式並非解決“多子類衍生的多繼承”問題，Decorator模式應用的要點在於解決“主體類在多個方向上的擴展功能”--是為“裝飾”的含義。

3.1、裝飾模式的優點

1）把抽象介面與其實現解耦。

2）抽象和實現可以獨立擴展，不會影響到對方。

3）實現細節對客戶透明，對用於隱藏了具體實現細節。

3.2、裝飾模式的缺點

1）增加了系統的複雜度

3.3、在以下情況下應當使用橋接模式

1）如果一個系統需要在構件的抽象化角色和具體化角色之間添加更多的靈活性，避免在兩個層次之間建立靜態的聯繫。

2）設計要求實現化角色的任何改變不應當影響客戶端，或者實現化角色的改變對客戶端是完全透明的。

3）需要跨越多個平臺的圖形和視窗系統上。

4）一個類存在兩個獨立變化的維度，且兩個維度都需要進行擴展。

四、.NET中裝飾模式的實現

在Net框架中，有一個類型很明顯使用了“裝飾模式”，這個類型就是Stream。Stream類型是一個抽象介面，它在System.IO命名空間裡面，它其實就是

Component。FileStream、NetworkStream、MemoryStream都是實體類ConcreteComponent。右邊的BufferedStream、CryptoStream是裝飾對象，它們都是

繼承了Stream介面。

Stream就相當於Component，定義裝飾的對象，FileStream就是要裝飾的對象，BufferedStream是裝飾對象。

我們看看BufferedStream的部分定義：

public sealed class BufferedStream : Stream
{
    private const int _DefaultBufferSize = 4096;

    private Stream _stream;

    //……
}

結構很簡單，對比結構圖看吧。

五、總結

這個模式有點像包餃子，ConcreteComponent其實是餃子餡，Decorator就像餃子皮一樣，包什麼皮就有什麼的樣子，皮和皮也可以嵌套，當然我們生活中

的餃子只是包一層皮。其實手機也是一個裝飾模式使用的好例子，早期的手機只有接打電話的功能，然後可以發簡訊和彩信，再後可以拍照了。現在的手機功

能很豐富，其結果也類似裝飾的結果。隨著社會的進步和技術發展，模塊化的手機也出現了，其設計原理越來越接近“裝飾模式”。不光是手機，我們身邊的很

多家用電器也有類似的發展經歷，讓我們努力發現生活中的真理吧，然後再在軟體環境中慢慢體會。