侧边栏壁纸
博主头像
孔子说JAVA博主等级

成功只是一只沦落在鸡窝里的鹰,成功永远属于自信且有毅力的人!

  • 累计撰写 297 篇文章
  • 累计创建 134 个标签
  • 累计收到 4 条评论

目 录CONTENT

文章目录

JAVA设计模式之装饰器模式

孔子说JAVA
2019-11-15 / 0 评论 / 0 点赞 / 104 阅读 / 3,459 字 / 正在检测是否收录...

1、装饰器模式/包装模式(Decorator)的定义

装饰器模式又名包装(Wrapper)模式。装饰器模式以对客户端透明的方式拓展对象的功能,是继承关系的一种替代方案。

2、模式(Decorator)优缺点

装饰器模式是一种结构型设计模式。其主要优缺点如下:

优点:

  1. 装饰模式与继承关系的目的都是要拓展对象的功能,但是装饰模式可以提供比继承更多的灵活性。装饰模式允许系统动态决定“贴上”一个需要的“装饰”,或者“除掉”一个不需要的“装饰”。继承关系则不同,继承关系是静态的,它在系统运行前就决定了。
  2. 通过不同的具体装饰类以及这些装饰类的排列组合,设计师可以创造出更多不同行为的组合。
  3. 装饰者类可以在被装饰者的行为前面或后面加上自己的行为,甚至取代被装饰者的行为,达到特定的目的。
  4. 装饰模式是继承关系的一个替代方案。我们看装饰类Decorator,不管装饰多少层,返回的对象还是Component,实现的还是is-a的关系

缺点:

  1. 由于使用装饰模式,可以比使用继承关系需要较少数目的类。使用较少的类,当然使设计比较易于进行。但是,在另外一方面,使用装饰模式会产生比使用继承关系所产生的更多的对象。而更多的对象会使得查找错误更为困难,特别是这些对象在看上去极为相似的时候。(可以用无数个装饰者包装一个组件,装饰者类会导致设计中出现许多小对象,过度使用会让程序变的复杂)

跟适配器比较:

image-1649382458073

  1. 理想的装饰器模式的装饰者接口跟组件接口应该保持一模一样,这样每次传入一个组件进去,都只对组件接口的各个方法增加功能,返回依旧由组件接口接收,这样调用同一个对象的同一个方法会有不同的实现,调用者完全不必要知道具体调用的是哪个对象,这个也称之为透明装饰器;
  2. 如果装饰者接口跟组件接口不一致,装饰者接口对组件接口方法进行了扩增,也是增加了新功能,但是如果还是用原组件接口来接收的话,新增的方法需要向下转型才能使用,这就违背了装饰器的初衷,但是组件接口中的方法仍然可以正常使用,因此这种可称之为半透明装饰器;
  3. 如果只是需要将原来对象或者类转换成另外一个我们需要的对象接口,不增加新功能,这种就是适配器;
  4. 简单的来理解的话,装饰器用来新加功能,适配器只是用来转换功能;

3、模式(Decorator)适用环境

  1. 在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责
  2. 处理那些可以撤销的职责
  3. 当你需要一个能够代替子类的类,借助它提供额外方法时。(当不能采用生成子类的方式进行扩充时)

4、模式(Decorator)的结构

image-1649382531212

装饰器模式涉及4个角色:

  • 抽象构件(Component)角色:给出一个抽象接口,已规范准备接收附加责任的对象。
  • 具体构件(ConcreteComponent)角色:定义一个将要接收附加责任的类
  • 装饰(Decorator)角色:持有一个构件(Component)对象的实例,并定义一个与抽象构件接口一致的接口。
  • 具体装饰(ConcreteDecorator)角色:负责给构件对象“贴上”附加的责任。

5、模式(Decorator)的应用实例

假设我去买咖啡,首先服务员给我冲了一杯原味咖啡,我希望服务员给我加些牛奶和白糖混合入原味咖啡中。使用装饰器模式就可以解决这个问题。

咖啡接口,定义了获取花费和配料的接口。

/**
 * 咖啡
 */
interface Coffee {
    /** 获取价格 */
    double getCost();
    /** 获取配料 */
    String getIngredients();
}

原味咖啡,实现Coffe接口,花费1元,配料中,只有咖啡

/**
 * 原味咖啡
 */
class SimpleCoffee implements Coffee {

    @Override
    public double getCost() {
        return 1;
    }

    @Override
    public String getIngredients() {
        return "Coffee";
    }
}

咖啡对象的装饰器类 ,同样实现Coffee接口,定义一个Coffe对象的引用,在构造器中进行初始化。并且将getCost()和getIntegredients()方法转发给被装饰对象。

/**
 * 咖啡的"装饰器",可以给咖啡添加各种"配料"
 */
abstract class CoffeeDecorator implements Coffee {
    protected final Coffee decoratedCoffee;

    /**
     * 在构造方法中,初始化咖啡对象的引用
     */
    public CoffeeDecorator(Coffee coffee) {
        decoratedCoffee = coffee;
    }

    /**
     * 装饰器父类中直接转发"请求"至引用对象
     */
    public double getCost() {
        return decoratedCoffee.getCost();
    }

    public String getIngredients() {
        return decoratedCoffee.getIngredients();
    }
}

具体的装饰器类 ,负责往咖啡中“添加”牛奶,注意看getCost()方法和getIngredients()方法,可以在转发请求之前或者之后,增加功能。如果是代理模式,这里的结构就有所不同,通常代理模式根据运行时的条件来判断是否转发请求。

/**
 * 此装饰类混合"牛奶"到原味咖啡中
 */
class WithMilk extends CoffeeDecorator {

    public WithMilk(Coffee coffee) {
        super(coffee);
    }

    @Override
    public double getCost() {
        double additionalCost = 0.5;
        return super.getCost() + additionalCost;
    }

    @Override
    public String getIngredients() {
        String additionalIngredient = "milk";
        return super.getIngredients() + ", " + additionalIngredient;
    }
}

另一个具体装饰器类 ,用来给咖啡加糖,一样的逻辑。

class WithSugar extends CoffeeDecorator {

    public WithSugar(Coffee coffee) {
        super(coffee);
    }

    @Override
    public double getCost() {
        return super.getCost() + 1;
    }

    @Override
    public String getIngredients() {
        return super.getIngredients() + ", Sugar";
    }
}

客户端使用装饰器模式 ,是不是与java中的io使用方式很像?

public class DecoratorDemo {

    static void print(Coffee c) {
        System.out.println("花费了: " + c.getCost());
        System.out.println("配料: " + c.getIngredients());
        System.out.println("============");
    }

    public static void main(String[] args) {
        //原味咖啡
        Coffee c = new SimpleCoffee();
        print(c);

        //增加牛奶的咖啡
        c = new WithMilk(c);
        print(c);

        //再加一点糖
        c = new WithSugar(c);
        print(c);
    }
}

输出结果:

花费了: 1.0
配料: Coffee
============
花费了: 1.5
配料: Coffee, milk
============
花费了: 2.5
配料: Coffee, milk, Sugar
============

6、总结

从上个例子可以看出,装饰器模式的结构很像代理模式,装饰器模式的请求转发过程很像职责炼模式,只不过:

  • 职责链模式在转发请求过程中,最多只有一个对象会处理请求,而装饰器模式则有多个对象处一个请求。

装饰器模式是代替增加子类的一种解决方案,体现了聚合/合成复用原则的思想,尽量使用组合的方式来扩展功能,这样就把基本功能和扩展功能解耦了,使得代码可复用,可维护,灵活。关键点在于装饰器模式可以动态地为对象增加扩展功能。

0

评论区