.Net结构型设计模式之装饰模式(Decorator)

目录
  • 一、动机(Motivate)
  • 二、意图(Intent)
  • 三、结构图(Structure)
  • 四、模式的组成
  • 五 、装饰模式的具体代码实现
  • 六、装饰模式的实现要点:
    • 1、装饰模式的优点:
    • 2、装饰模式的缺点:
    • 3、在以下情况下应当使用桥接模式:
  • 七、.NET 中装饰模式的实现

一、动机(Motivate)

在房子装修的过程中,各种功能可以相互组合,来增加房子的功用。类似的,如果我们在软件系统中,要给某个类型或者对象增加功能,如果使用“继承”的方案来写代码,就会出现子类暴涨的情况。比如:IMarbleStyle是大理石风格的一个功能,IKeepWarm是保温的一个接口定义,IHouseSecurity是房子安全的一个接口,就三个接口来说,House是我们房子,我们的房子要什么功能就实现什么接口,如果房子要的是复合功能,接口不同的组合就有不同的结果,这样就导致我们子类膨胀严重,如果需要在增加功能,子类会成指数增长。这个问题的根源在于我们“过度地使用了继承来扩展对象的功能”,由于继承为类型引入的静态特质(所谓静态特质,就是说如果想要某种功能,我们必须在编译的时候就要定义这个类,这也是强类型语言的特点。静态,就是指在编译的时候要确定的东西;动态,是指运行时确定的东西),使得这种扩展方式缺乏灵活性;并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展功能的组合)会导致更多子类的膨胀(多继承)。如何使“对象功能的扩展”能够根据需要来动态(即运行时)地实现?同时避免“扩展功能的增多”带来的子类膨胀问题?从而使得任何“功能扩展变化”所导致的影响降为最低?

二、意图(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模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

1、装饰模式的优点:

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

2、装饰模式的缺点:

  • 增加了系统的复杂度

3、在以下情况下应当使用桥接模式:

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

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

到此这篇关于.Net结构型设计模式之装饰模式(Decorator)的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • .Net结构型设计模式之适配器模式(Adapter)

    一.动机(Motivation) 在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的. 如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口? 二.意图(Intent) 将一个类的接口转换成客户希望的另一个接口.Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作. 例说Adapter应用 这种实际上是一种委派的调用,本来是发送请求给MyStack,但是M

  • .Net结构型设计模式之桥接模式(Bridge)

    一.动机(Motivation) 在很多游戏场景中,会有这样的情况:[装备]本身会有的自己固有的逻辑,比如枪支,会有型号的问题,同时现在很多的游戏又在不同的介质平台上运行和使用,这样就使得游戏的[装备]具有了两个变化的维度——一个变化的维度为“平台的变化”,另一个变化的维度为“型号的变化”.如果我们要写代码实现这款游戏,难道我们针对每种平台都实现一套独立的[装备]吗?复用在哪里?如何应对这种“多维度的变化”?如何利用面向对象技术来使得[装备]可以轻松地沿着“平台”和“型号”两个方向变化,而不引入

  • .Net结构型设计模式之装饰模式(Decorator)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五 .装饰模式的具体代码实现 六.装饰模式的实现要点: 1.装饰模式的优点: 2.装饰模式的缺点: 3.在以下情况下应当使用桥接模式: 七..NET 中装饰模式的实现 一.动机(Motivate) 在房子装修的过程中,各种功能可以相互组合,来增加房子的功用.类似的,如果我们在软件系统中,要给某个类型或者对象增加功能,如果使用“继承”的方案来写代码,就会出现子类暴涨的情况.比如:IMar

  • .Net结构型设计模式之组合模式(Composite)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五.组合模式的具体代码实现 1.透明式的组合模式 2.安全式的组合模式 六.组合模式的实现要点: 组合模式的优点: 组合模式的缺点: 在以下情况下应该考虑使用组合模式: 七..NET 中组合模式的实现 一.动机(Motivate) 在我们的操作系统中有文件夹的概念,文件夹可以包含文件夹,可以嵌套多层,最里面包含的是文件,这个概念和“俄罗斯套娃”很像.当然还有很多的例子,例如我们使用系统

  • .Net结构型设计模式之代理模式(Proxy)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五.代理模式的分类: 六.代理模式的具体实现 七.代理模式的实现要点: 1.代理模式的优点: 2.代理模式的缺点: 3.代理模式的使用场景: 八..NET 中代理模式的实现 九.总结 一.动机(Motivate) 在面向对象系统中,有些对象由于某种原因(比如对象创建的开销很大,或者某些操作需要安全控制,或者需要进程外的访问等),直接访问会给使用者.或者系统结构带来很多麻烦.如何在不失去

  • .Net结构型设计模式之享元模式(Flyweight)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五.享元模式的具体代码实现 六.享元模式的实现要点: 1.享元模式的优点 2.享元模式的缺点 3.在下面所有条件都满足时,可以考虑使用享元模式: 七..NET 中享元模式的实现 一.动机(Motivate) 在软件系统中,采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价——主要指内存需求方面的代价.如何在避免大量细粒度对象问题的同时,让外部客户程序

  • .Net结构型设计模式之外观模式(Facade)

    目录 一.动机(Motivate) 二.意图(Intent) 三.结构图(Structure) 四.模式的组成 五.外观模式的具体实现 六.实现要点: 1.外观模式的优点: 2.外观模式的缺点: 3.在以下情况下可以考虑使用外观模式: 七.NET 中外观模式的实现 一.动机(Motivate) 在软件系统开发的过程中,当组件的客户(即外部接口,或客户程序)和组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的演化,这种过多的耦合面临很多变化的挑战.如何简化外部客户程序和系统间的交互

  • Java结构型设计模式之享元模式示例详解

    目录 享元模式 概述 目的 应用场景 优缺点 主要角色 享元模式结构 内部状态和外部状态 享元模式的基本使用 创建抽象享元角色 创建具体享元角色 创建享元工厂 客户端调用 总结 享元模式实现数据库连接池 创建数据库连接池 使用数据库连接池 享元模式 概述 享元模式(Flyweight Pattern)又称为轻量级模式,是对象池的一种实现.属于结构型模式. 类似于线程池,线程池可以避免不停的创建和销毁多个对象,消耗性能.享元模式提供了减少对象数量从而改善应用所需的对象结构的方式. 享元模式尝试重用

  • Java结构型设计模式中代理模式示例详解

    目录 代理模式 分类 主要角色 作用 静态代理与动态代理的区别 静态代理的基本使用 创建抽象主题 创建真实主题 创建代理主题 客户端调用 JDK动态代理的基本使用 创建抽象主题 创建真实主题 创建代理主题 客户端调用 小优化 CGLIB动态代理的基本使用 创建抽象主题 创建真实主题 创建代理主题 客户端调用 小优化 CGLIB与JDK动态代理区别 1.执行条件 2.实现机制 3.性能 代理模式 代理模式(Proxy Pattern)属于结构型模式. 它是指为其他对象提供一种代理以控制对这个对象的

  • Java结构型设计模式中建造者模式示例详解

    目录 建造者模式 概述 角色 优缺点 应用场景 基本使用 创建产品类 创建建造者类 使用 链式写法 创建产品类与建造者类 使用 建造者模式 概述 建造者模式(Builder Pattern)属于创建型模式. 它是将一个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示. 简而言之:建造者模式就是使用多个简单的对象一步一步构建成一个复杂的对象. 建造者模式适用于创建对象需要很多步骤,但是步骤的顺序不一定固定.如果一个对象有非常复杂的内部结构(很多属性),可以将复杂对象的创建和使用进行分

随机推荐