本筆記摘抄自：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就像餃子皮一樣，包什么皮就有什么的樣子，皮和皮也可以嵌套，當然我們生活中
的餃子只是包一層皮，其實手機也是一個裝飾模式使用的好例子，早期的手機只有接打電話的功能，然后可以發短信和彩信，再后可以拍照了，現在的手機功
能很豐富，其結果也類似裝飾的結果，隨著社會的進步和技術發展，模塊化的手機也出現了，其設計原理越來越接近“裝飾模式”，不光是手機，我們身邊的很
多家用電器也有類似的發展經歷，讓我們努力發現生活中的真理吧，然后再在軟體環境中慢慢體會，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/77388.html
標籤：C#