李建忠设计模式——装饰模式

1.“单一职责”模式

• 在软件组件的设计中，如果责任划分不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。
• 典型模式

1. Decorator
2. Bridge

2.装饰模式（Decorator）

1.动机

• 在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质（所谓静态特质，就是说如果想要某种功能，我们必须在编译的时候就要定义这个类，这也是强类型语言的特点。静态，就是指在编译的时候要确定的东西；动态，是指运行时确定的东西），，使得这种扩展方式缺乏灵活性；并且随着子类的增大（扩展功能的增多），各种子类的组合（扩展功能的组合），会导致更多子类的膨胀。
• 如何使“对象功能的扩展”能够根据需要来动态地实现呢？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响降为最低？

2.定义

动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码&减少子类个数）。——《设计模式》GoF

3.结构图

4.模式的组成角色

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

3.实例

1.描述

购买的是毛坯房。如果我想要房子的内饰是大理石风格的，我们只要在毛坯房的基础之上用大理石风格的材料装修就可以，我们当然不可能为了要一个装修风格，就把刚刚盖好的房子拆了在重新来过。房子装修好了，我们就住了进来，很开心。过了段时间，我们发现我们的房子在冬季比较冷，于是我就想给我们的房子增加保暖的功能，装修好的房子我们可以继续居住，我们只是在房子外面加一层保护层就可以了。又过了一段时间，总是有陌生人光顾，所以我们想让房子更安全，于是我们在外墙和房顶加装安全摄像头，同时门窗也增加安全系统。随着时间的流逝，我们可能会根据我们的需求增加相应的功能，期间，我们的房子可以正常使用，加上什么设施就有了相应的功能。

2.代码实现

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
//装饰模式实例：装修房子
namespace Pattern
{
    /// <summary>
    /// Component:抽象构件角色
    /// </summary>
    public abstract class House
    {
        public abstract void Renovation();
    }
    /// <summary>
    /// Contrete Component:具体构件角色
    /// </summary>
    public class Myhouse:House
    {
        public override void Renovation()
        {
            Console.WriteLine("it's my house!");
        }
    }

    /// <summary>
    /// Decorator:装饰角色
    /// </summary>
    public class Decoratorhouse : House
    {
        private House house;
        protected  Decoratorhouse(House house)
        {
            this.house = house;
        }
        public override void Renovation()
        {
            if(this.house!=null)
            {
                this.house.Renovation();
            }
        }
    }

    /// <summary>
    /// 具体装饰角色
    /// 铺地板
    /// </summary>
    public class Flooring:Decoratorhouse
    {
        public Flooring(House house) : base(house) { }
        public override void Renovation()
        {
            base.Renovation();
            Console.WriteLine("铺地板！");
        }
    }

    /// <summary>
    /// 具体装饰角色
    /// 保温
    /// </summary>
    public class Warming:Decoratorhouse
    {
         public Warming(House house) : base(house) { }
         public override void Renovation()
        {
            base.Renovation();
            Console.WriteLine("增加保温系统！");
        }
    }
    
    class Program
    {
        static void Main(string[] args)
        {
            //运行时装配

            //这是我的房子
            Myhouse myhouse = new Myhouse();
            
            //铺地板
            Flooring floor = new Flooring(myhouse);
            floor.Renovation();

            //安装保温系统
            Warming warm = new Warming(myhouse);
            warm.Renovation();
            Console.ReadKey();
            
        }
    }
}

3.要点总结

• 通过采用组合而非继承的手法，Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的“灵活性差”和“多子类衍生问题”。
• Decorator类在接口上表现为is-a Componenet的继承关系，即Decorator类Component类所具有的的接口。但实际上又表现为has-a Componenet的组合关系，即Decorator类又使用了另一个Component类。
• Decorator模式的目的并非解决“多子类衍生的多继承”问题。Decorator模式应用的要点在于解决“主题类在多个方向上的扩展功能”——是为“装饰”的含义。

4.Net中装饰模式的实现

  在Net框架中，有一个类型很明显的使用了“装饰模式”，这个类型就是Stream。Stream类型是一个抽象接口，它在System.IO命名空间里面，它其实就是Component。FileStream、NetworkStream、MemoryStream都是实体类ConcreteComponent。右边的BufferedStream、CryptoStream是装饰对象，它们都是继承了Stream接口的。

   如图：

       

    Stream就相当于Component，定义装饰的对象，FileStream就是要装饰的对象，BufferedStream是装饰对象。

参考：

https://www.cnblogs.com/PatrickLiu/p/7723225.html

https://www.bilibili.com/video/BV1Vb411c7uL?p=6