结构型模式(二) 装饰模式（Decorator Pattern）

动机（Motivate）

如何使“对象功能的扩展”能够根据需要来动态（即运行时）地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响降为最低？

意图（Intent）

动态地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类更为灵活。 —— 《设计模式》GoF

结构图（Structure）

模式的组成

在装饰模式中的各个角色有：
（1）、抽象构件角色（Component）：给出一个抽象接口，以规范准备接收附加责任的对象。
（2）、具体构件角色（Concrete Component）：定义一个将要接收附加责任的类。
（3）、装饰角色（Decorator）：持有一个构件（Component）对象的实例，并实现一个与抽象构件接口一致的接口。
（4）、具体装饰角色（Concrete Decorator）：负责给构件对象添加上附加的责任。

应用：

/// <summary>
/// 该抽象类就是房子抽象接口的定义，该类型就相当于是Component类型，是饺子馅，需要装饰的，需要包装的
/// </summary>
public abstract class House
{
    public abstract void Renovation();//房子的装修方法--该操作相当于Component类型的Operation方法
}

/// <summary>
/// 该抽象类就是装饰接口的定义，该类型就相当于是Decorator类型，如果需要具体的功能，可以子类化该类型
/// </summary>
public abstract class DecorationStrategy : House //关键点之二，体现关系为Is-a，有这这个关系，装饰的类也可以继续装饰了
{
    //通过组合方式引用Decorator类型，该类型实施具体功能的增加这是关键点之一，包含关系，体现为Has-a
    protected House _house;

    protected DecorationStrategy(House house)//通过构造器注入，初始化平台实现
    {
        this._house = house;
    }

    public override void Renovation()   //该方法就相当于Decorator类型的Operation方法
    {
        if (this._house != null)
        {
            this._house.Renovation();
        }
    }
}

/// <summary>
/// PatrickLiu的房子，我要按我的要求做房子，相当于ConcreteComponent类型，这就是我们具体的饺子馅，我个人比较喜欢韭菜馅
/// </summary>
public sealed class MyHouse : House
{
    public override void Renovation()
    {
        Console.WriteLine("装修PatrickLiu的房子");
    }
}

/// <summary>
/// 具有安全功能的设备，可以提供监视和报警功能，相当于ConcreteDecoratorA类型
/// </summary>
public sealed class HouseSecurityDecorator : DecorationStrategy
{
    public HouseSecurityDecorator(House house) : base(house) { }

    public override void Renovation()
    {
        base.Renovation();
        Console.WriteLine("增加安全系统");
    }
}

/// <summary>
/// 具有保温接口的材料，提供保温功能，相当于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();
        //房子就有了安全系统了

        //如果我既要安全系统又要保暖呢，继续装饰就行
        DecorationStrategy securityAndWarmHouse = new HouseSecurityDecorator(securityHouse);
        securityAndWarmHouse.Renovation();
    }
}

装饰模式的实现要点：

通过采用组合、而非继承的手法，Decorator模式实现了在运行时动态地扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。
Component类在Decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且Decorator类对于Component类应该透明——换言之Component类无需知道Decorator类，Decorator类是从外部来扩展Component类的功能。
Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。我们可以使用一个或者多个Decorator对象来“装饰”一个Component对象，且装饰后的对象仍然是一个Component对象。
Decorator模式并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

装饰模式的优点：

把抽象接口与其实现解耦。
抽象和实现可以独立扩展，不会影响到对方。
实现细节对客户透明，对用于隐藏了具体实现细节。

装饰模式的缺点：

增加了系统的复杂度

在以下情况下应当使用桥接模式：

如果一个系统需要在构件的抽象化角色和具体化角色之间添加更多的灵活性，避免在两个层次之间建立静态的联系。
设计要求实现化角色的任何改变不应当影响客户端，或者实现化角色的改变对客户端是完全透明的。
需要跨越多个平台的图形和窗口系统上。
一个类存在两个独立变化的维度，且两个维度都需要进行扩展。

四、.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;
}