一、動機(jī)（Motivate）

在房子裝修的過程中，各種功能可以相互組合，來增加房子的功用。類似的，如果我們在軟件系統(tǒng)中，要給某個類型或者對象增加功能，如果使用“繼承”的方案來寫代碼，就會出現(xiàn)子類暴漲的情況。比如：IMarbleStyle是大理石風(fēng)格的一個功能，IKeepWarm是保溫的一個接口定義，IHouseSecurity是房子安全的一個接口，就三個接口來說，House是我們房子，我們的房子要什么功能就實(shí)現(xiàn)什么接口，如果房子要的是復(fù)合功能，接口不同的組合就有不同的結(jié)果，這樣就導(dǎo)致我們子類膨脹嚴(yán)重，如果需要在增加功能，子類會成指數(shù)增長。這個問題的根源在于我們“過度地使用了繼承來擴(kuò)展對象的功能”，由于繼承為類型引入的靜態(tài)特質(zhì)（所謂靜態(tài)特質(zhì)，就是說如果想要某種功能，我們必須在編譯的時候就要定義這個類，這也是強(qiáng)類型語言的特點(diǎn)。靜態(tài)，就是指在編譯的時候要確定的東西；動態(tài)，是指運(yùn)行時確定的東西），使得這種擴(kuò)展方式缺乏靈活性；并且隨著子類的增多（擴(kuò)展功能的增多），各種子類的組合（擴(kuò)展功能的組合）會導(dǎo)致更多子類的膨脹（多繼承）。如何使“對象功能的擴(kuò)展”能夠根據(jù)需要來動態(tài)（即運(yùn)行時）地實(shí)現(xiàn)？同時避免“擴(kuò)展功能的增多”帶來的子類膨脹問題？從而使得任何“功能擴(kuò)展變化”所導(dǎo)致的影響降為最低？

二、意圖（Intent）

動態(tài)地給一個對象增加一些額外的職責(zé)。就增加功能而言，Decorator模式比生成子類更為靈活。        ——  《設(shè)計(jì)模式》GoF

三、結(jié)構(gòu)圖（Structure）

四、模式的組成

在裝飾模式中的各個角色有：
（1）、抽象構(gòu)件角色（Component）：給出一個抽象接口，以規(guī)范準(zhǔn)備接收附加責(zé)任的對象。
（2）、具體構(gòu)件角色（Concrete Component）：定義一個將要接收附加責(zé)任的類。
（3）、裝飾角色（Decorator）：持有一個構(gòu)件（Component）對象的實(shí)例，并實(shí)現(xiàn)一個與抽象構(gòu)件接口一致的接口。
（4）、具體裝飾角色（Concrete Decorator）：負(fù)責(zé)給構(gòu)件對象添加上附加的責(zé)任。

五 、裝飾模式的具體代碼實(shí)現(xiàn)

繼續(xù)拿蓋房子來說事吧。

/// <summary>
/// 該抽象類就是房子抽象接口的定義，該類型就相當(dāng)于是Component類型，是餃子餡，需要裝飾的，需要包裝的
/// </summary>
public abstract class House
{
    public abstract void Renovation();//房子的裝修方法--該操作相當(dāng)于Component類型的Operation方法
}

/// <summary>
/// 該抽象類就是裝飾接口的定義，該類型就相當(dāng)于是Decorator類型，如果需要具體的功能，可以子類化該類型
/// </summary>
public abstract class DecorationStrategy : House //關(guān)鍵點(diǎn)之二，體現(xiàn)關(guān)系為Is-a，有這這個關(guān)系，裝飾的類也可以繼續(xù)裝飾了
{
    //通過組合方式引用Decorator類型，該類型實(shí)施具體功能的增加這是關(guān)鍵點(diǎn)之一，包含關(guān)系，體現(xiàn)為Has-a
    protected House _house;

    protected DecorationStrategy(House house)//通過構(gòu)造器注入，初始化平臺實(shí)現(xiàn)
    {
        this._house = house;
    }

    public override void Renovation()   //該方法就相當(dāng)于Decorator類型的Operation方法
    {
        if (this._house != null)
        {
            this._house.Renovation();
        }
    }
}

/// <summary>
/// PatrickLiu的房子，我要按我的要求做房子，相當(dāng)于ConcreteComponent類型，這就是我們具體的餃子餡，我個人比較喜歡韭菜餡
/// </summary>
public sealed class MyHouse : House
{
    public override void Renovation()
    {
        Console.WriteLine("裝修PatrickLiu的房子");
    }
}

/// <summary>
/// 具有安全功能的設(shè)備，可以提供監(jiān)視和報(bào)警功能，相當(dāng)于ConcreteDecoratorA類型
/// </summary>
public sealed class HouseSecurityDecorator : DecorationStrategy
{
    public HouseSecurityDecorator(House house) : base(house) { }

    public override void Renovation()
    {
        base.Renovation();
        Console.WriteLine("增加安全系統(tǒng)");
    }
}

/// <summary>
/// 具有保溫接口的材料，提供保溫功能，相當(dāng)于ConcreteDecoratorB類型
/// </summary>
public sealed class KeepWarmDecorator : DecorationStrategy
{
    public KeepWarmDecorator(House house) : base(house) { }

    public override void Renovation()
    {
       base.Renovation();
        Console.WriteLine("增加保溫的功能");
    }
}

public class Program
{
    static void Main()
    {

        House myselfHouse = new MyHouse();//這就是我們的餃子餡，需要裝飾的房子

        DecorationStrategy securityHouse = new HouseSecurityDecorator(myselfHouse);
        securityHouse.Renovation();
        //房子就有了安全系統(tǒng)了

        //如果我既要安全系統(tǒng)又要保暖呢，繼續(xù)裝飾就行
        DecorationStrategy securityAndWarmHouse = new HouseSecurityDecorator(securityHouse);
        securityAndWarmHouse.Renovation();
    }
}

六、裝飾模式的實(shí)現(xiàn)要點(diǎn)：

• 通過采用組合、而非繼承的手法，Decorator模式實(shí)現(xiàn)了在運(yùn)行時動態(tài)地?cái)U(kuò)展對象功能的能力，而且可以根據(jù)需要擴(kuò)展多個功能。避免了單獨(dú)使用繼承帶來的“靈活性差”和“多子類衍生問題”。
• Component類在Decorator模式中充當(dāng)抽象接口的角色，不應(yīng)該去實(shí)現(xiàn)具體的行為。而且Decorator類對于Component類應(yīng)該透明——換言之Component類無需知道Decorator類，Decorator類是從外部來擴(kuò)展Component類的功能。
• Decorator類在接口上表現(xiàn)為is-a Component的繼承關(guān)系，即Decorator類繼承了Component類所具有的接口。但在實(shí)現(xiàn)上又表現(xiàn)為has-a Component的組合關(guān)系，即Decorator類又使用了另外一個Component類。我們可以使用一個或者多個Decorator對象來“裝飾”一個Component對象，且裝飾后的對象仍然是一個Component對象。
• Decorator模式并非解決“多子類衍生的多繼承”問題，Decorator模式應(yīng)用的要點(diǎn)在于解決“主體類在多個方向上的擴(kuò)展功能”——是為“裝飾”的含義。

1、裝飾模式的優(yōu)點(diǎn)：

• 把抽象接口與其實(shí)現(xiàn)解耦。
• 抽象和實(shí)現(xiàn)可以獨(dú)立擴(kuò)展，不會影響到對方。
• 實(shí)現(xiàn)細(xì)節(jié)對客戶透明，對用于隱藏了具體實(shí)現(xiàn)細(xì)節(jié)。

2、裝飾模式的缺點(diǎn)：

• 增加了系統(tǒng)的復(fù)雜度

3、在以下情況下應(yīng)當(dāng)使用橋接模式：

• 如果一個系統(tǒng)需要在構(gòu)件的抽象化角色和具體化角色之間添加更多的靈活性，避免在兩個層次之間建立靜態(tài)的聯(lián)系。
• 設(shè)計(jì)要求實(shí)現(xiàn)化角色的任何改變不應(yīng)當(dāng)影響客戶端，或者實(shí)現(xiàn)化角色的改變對客戶端是完全透明的。
• 需要跨越多個平臺的圖形和窗口系統(tǒng)上。
• 一個類存在兩個獨(dú)立變化的維度，且兩個維度都需要進(jìn)行擴(kuò)展。

七、.NET 中裝飾模式的實(shí)現(xiàn)

在Net框架中，有一個類型很明顯的使用了“裝飾模式”，這個類型就是Stream。Stream類型是一個抽象接口，它在System.IO命名空間里面，它其實(shí)就是Component。FileStream、NetworkStream、MemoryStream都是實(shí)體類ConcreteComponent。右邊的BufferedStream、CryptoStream是裝飾對象，它們都是繼承了Stream接口的。

如圖：

Stream就相當(dāng)于Component，定義裝飾的對象，F(xiàn)ileStream就是要裝飾的對象，BufferedStream是裝飾對象。我們看看BufferedStream的定義，部分定義了。

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

到此這篇關(guān)于.Net結(jié)構(gòu)型設(shè)計(jì)模式之裝飾模式（Decorator）的文章就介紹到這了。希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論