C#设计模式-装饰器模式（Decorator Pattern）

引言

当咱们完成一个软件产品开发后就须要对其进行各类测试，适配快速迭代下质量的保障。当有一个完善的产品的对象后，若是咱们想要给他添加一个测试功能，那么咱们能够用一个新的类去装饰它来实现对原有对象职责的扩展。新的类称为“装饰者”，原有的对象称为“被装饰者”。这种模式被称为装饰器模式。

概念

装饰器模式（Decorator Pattern）容许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是做为现有的类的一个包装。
这种模式建立了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。
咱们经过下面的实例来演示装饰器模式的用法。其中，咱们将把一个形状装饰上不一样的颜色，同时又不改变形状类。

结构图

装饰器模式中的角色：

• 抽象构件(Component)角色：声明封装器和被封装对象的公用接口。即给出一个抽象接口，已规范准备接收附加责任的对象。
• 具体构件(ConcreteComponent)角色：类是被封装对象所属的类。 它定义了基础行为， 但装饰类能够改变这些行为。
• 装饰(Decorator)角色：拥有一个指向被封装对象的引用成员变量。 该变量的类型应当被声明为通用部件接口， 这样它就能够引用具体的部件和装饰。 装饰基类会将全部操做委派给被封装的对象。
• 具体装饰(ConcreteDecorator)角色：定义了可动态添加到部件的额外行为。 具体装饰类会重写装饰基类的方法， 并在调用父类方法以前或以后进行额外的行为。负责给构件对象“贴上”附加的责任。

实现

实现一个开发完成后的产品，对其进行手工功能测试、自动化测试、压力测试。将产品做为被装饰者，也就是构件。各类测试做为装饰者，计算附加不一样的测试花费的总时间。

实现思路：

• 定义一个产品抽象类。
• 实现具体的产品，具体的产品继承产品抽象类。
• 定义一个测试类型的抽象装饰类，继承产品抽象类。
• 实现不一样类型的测试，继承测试类型的抽象装饰类。
• 使用时实例化一个产品，而后对产品进行附件不一样的测试类型。

using System;


namespace Decorator
{
    class Program
    {
        static void Main(string[] args)
        {
            Product a = new ProductA();
            Console.WriteLine($"未执行{a.Test}测试时总共花费时间{a.TotalTime}");
            a = new ManualTest(a);
            Console.WriteLine($"执行{a.Test}总共花费时间{a.TotalTime}");
            Console.WriteLine("=====================================");

            Product b = new ProductB();
            b = new ManualTest(b);
            b = new StressTest(b);
            b = new AutoTest(b);
            Console.WriteLine($"执行{b.Test}总共花费时间{b.TotalTime}");

            Console.Read();
        }
    }

    /// <summary>
    /// 一个项目产品，抽象构件
    /// </summary>
    public abstract class Product
    {
        public string Name { get; set; }
        public double SpendTime { get; set; }
        public abstract string Test { get; }
        public abstract double TotalTime { get; }
    }

    /// <summary>
    /// 具体的项目产品A，具体构件
    /// </summary>
    public class ProductA : Product
    {
        public ProductA()
        {
            Name = "ProductA";
            SpendTime = 0;
        }

        public override string Test => this.Name;
        public override double TotalTime => this.SpendTime;
    }

    /// <summary>
    /// 具体的项目产品B，具体构件
    /// </summary>
    public class ProductB : Product
    {
        public ProductB()
        {
            Name = "ProductB";
            SpendTime = 0;
        }

        public override string Test => this.Name;
        public override double TotalTime => this.SpendTime;
    }

    /// <summary>
    /// 测试类型，抽象装饰
    /// </summary>
    public abstract class TestType : Product
    {
        Product _product = null;

        public TestType(Product product)
        {
            _product = product;
        }

        public override string Test
        {
            get
            {
                return _product.Test + "+" + this.Name;
            }
        }

        public override double TotalTime
        {
            get
            {
                return _product.TotalTime + this.SpendTime;
            }
        }
    }

    /// <summary>
    /// 手工测试类型，具体装饰
    /// </summary>
    public class ManualTest : TestType
    {

        public ManualTest(Product product) : base(product)
        {
            Name = "手工测试";
            SpendTime = 200;
        }
    }

    /// <summary>
    /// 自动化测试类型，具体装饰
    /// </summary>
    public class AutoTest : TestType
    {

        public AutoTest(Product product) : base(product)
        {
            Name = "自动化测试";
            SpendTime = 100;
        }

    }

    /// <summary>
    /// 压力测试类型，具体装饰
    /// </summary>
    public class StressTest : TestType
    {
        public StressTest(Product product) : base(product)
        {
            Name = "压力测试";
            SpendTime = 200;
        }
    }

}

运行后结果：

未执行ProductA测试时总共花费时间0
执行ProductA+手工测试总共花费时间200
=====================================
执行ProductB+手工测试+压力测试+自动化测试总共花费时间500

应用场景

• 在无需修改代码的状况下便可使用对象， 且但愿在运行时为对象新增额外的行为时可使用装饰模式。由于装饰能将业务逻辑组织为层次结构，可为各层建立一个装饰， 在运行时将各类不一样逻辑组合成对象。 因为这些对象都遵循通用接口， 客户端代码能以相同的方式使用这些对象。
• 若是用继承来扩展对象行为的方案难以实现或者根本不可行，可使用装饰模式。

优缺点

^优势

• 无需建立新子类便可扩展对象的行为。
• 能够在运行时添加或删除对象的功能。
• 能够用多个装饰封装对象来组合几种行为。
• 装饰类和被装饰类能够独立发展，不会相互耦合。
• 单一职责原则。 能够将实现了许多不一样行为的一个大类拆分为多个较小的类。

缺点

• 在封装器栈中删除特定封装器比较困难。
• 实现行为不受装饰栈顺序影响的装饰比较困难。
• 各层的初始化配置代码看上去可能会很糟糕。