• 装饰模式 decorator


    面前对象是对现实的映射,而不仅仅是对现实中物体的映射,水果变成苹果是,我们开发员本能的会写父子两个类,没问题,那么有ABS的汽车和没有ABS的汽车你会写几个类呢?如果再加上国产和进口的区别呢?很快就会产生一堆堆的类,子类复子类,子类何其多!

    装饰模式的核心在于解决对象操作的具体方法甚至是方法本身的不确定,比如在类中新增一个方法。

    为啥叫装饰模式呢?我想是这样的,那天Gof在盖房子,房子盖好了,Erich Gamma说要能使用太阳能、Richard Helm说要能看电视、Ralph Johnson说给个篮球架吧, John Vlissides最离谱非要个游泳池,传统理念好像要盖四个房子,而且万一他们看不得别人的好,也要求再加就麻烦了,我们就装饰他,要太阳能的加个太阳热水器,不要的就拿走,反正是你要就加,不要就去,在国外装修和装饰是不是一个词呢,可能是吧。

     

    动机(Motivation

    上述描述的问题根源在于我们过度地使用了继承来扩展对象的功能,由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性;并且随着子类的增多(扩展功能的增 多),各种子类的组合(扩展功能的组合)会导致更多子类的膨胀(多继承)。

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

    Intent:动态给一个对象增加一些额外的职责

    使用Decorator比生成子类更灵活,尤其是需要进行功能组合时

     

    Decorator模式的几个要点

    •   通过采用组合、而非继承的手法, 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模式   应用的要点在于解决主体类在多个方向上的扩展功能”——是为装饰”      的含义。

    代码范例

    下面是传统的方式,写一些新的子类

    public class Tank

    {

     public abstract void run();

    }

    public T50:Tank

    {

     public override void run()

     {

    //Some privite code功能扩展

        base.run();

     };

     }

    public T75:Tank //类个子类

    {

     public override void run()

     {

    //Some privite code功能扩展

        base.run();

     };

     }

     class App

     {

        public static void Main()

    {

    //使用50new 50,使用75new75,如果需要该类5075的功能都有就要再建了 50&75

          Tank tank = new T50(); 

          Tank tank = new T75();

     }

     }

    }

    应用装饰模式

    public class Tank

    {

     public abstract void run();

    }

    public abstract class Decorator: Tank //这个类是用来规范接口的,不要也可以

     {

         private Tank _tank;//这里是关键,基于此装饰模式是属于组合架构

         public Decorator(Tank tank)

         {

           this._tank = tank;

         }

         public override void run()

         {

           _tank.run();

         }

     }

        public class DecoratorA:Decorator

     {

         public DecoratorA(Tank tank):base(tank) {     }

         public override void run()

         {

           base.run();

         }

     }

        public class DecoratorB:Decorator

     {

         public DecoratorB(Tank tank):base(tank) {     }

         public override void run()

         {

           base.run();

         }

     } 

     class App

     {

        public static void Main()

        {

          Tank tank = new T50();

          DecoratorA da = new DecoratorA(tank);// 第一层装饰

          DecoratorB db = new DecoratorA(da);// 第二层装饰

          //我们实际调用不再是tank,而是根据需要调用 da,或db

          //这也是为何装饰类用和被装饰对象继承于同一父类

        }

     }

     

    }

  • 相关阅读:
    Sublime Text3 包管理器、插件安装
    Sublime text3 安装
    VS中的波浪线
    VS的启动方式
    VS常用快捷键
    C#基础性问题
    nginx前端项目发布
    vue父子组件实现数据双向绑定
    常用在线echarts图表
    使用echarts地图踩坑记
  • 原文地址:https://www.cnblogs.com/xiachong/p/2451965.html
Copyright © 2020-2023  润新知