技術標籤：C#教程c#

本筆記摘抄自：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
        }
    }

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

執行結果如下：

三、裝飾模式的實現要點

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就像餃子皮一樣，包什麼皮就有什麼的樣子，皮和皮也可以巢狀，當然我們生活中

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

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

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