设计模式——装饰者模式

275 阅读4分钟

本文是阅读 Head First 设计模式——装饰者模式的总结。 这本书的教学模式很不错,个人很喜欢,由实际的案例由浅入深,循序渐进的让你明白良好的设计是多么的优雅迷人(回头看看自己的代码,WTF!)。 但是读第二遍的时候,居然想不起来这章节说了什么,到底怎么解决这个问题的。也就是说,看的时候爽快,看完了并没有应用到具体的Coding中。

这一章节的案例是:设计星巴兹咖啡系统

相关的背景:
星巴兹咖啡现在有四种咖啡:黑咖啡(HouseBlend)、深度烘焙咖啡(DarkRoast)、脱咖啡因咖啡(Decaf)、浓咖啡(Espresso)。
用户在购买咖啡时,可以要求在其中加入各种调料,例如:蒸奶(Steamed Milk)、豆浆(Soy)、摩卡(Mocha)或覆盖奶泡(Whip)。会根据所加入的调料收取不同的费用,所以订单系统必须考虑到这些调料的价格。

原先的类设计

类图

如果按照这种模式,在某种咖啡中加入调料,那么就是一个新的子类,继承 Beverage ,实现自己的 cost() 方法,算出咖啡以及调料的价格。以此类推,这是一个类爆炸的系统,有多少种花样就要为此设计多少类。

很明显,星巴兹为自己制作了一个维护噩梦。如果牛奶涨价了,怎么办?新增一种焦糖风味调料时,怎么办?

很明显,这种设计是有致命的缺陷的。

优化方案

利用实例变量和继承,可以追踪调料,没必要去设计这么多类。

类图

这样设计有哪些缺陷呢?

  • 调料价格变化时,需要更改现有代码
  • 出现新的调料,需要添加新的方法,并改动超类中的cost()方法
  • 以后开发新的饮料,对于这些饮料,某些调料并不适合,但是这个设计中,子类仍需继承那些不需要的方法
  • 万一顾客想要双倍摩卡怎么办?

当然这种设计,违反了基本的开闭原则,类应该对扩展开放,对修改关闭。

装饰者模式

从上面的方案来看,我们利用继承无法完全解决问题,现在遇到的问题有:类数量爆炸、设计死板,以及基类加入的新功能并不适用所有的子类。

所以,在这里要采用不一样的做法:以饮料为主体,然后再运行时以调料来“装饰”(decorate)饮料。比如,如果顾客想要摩卡和奶泡深焙咖啡,那么,要做的是:

  1. 拿一个深焙咖啡(DarkRoast)对象
  2. 以摩卡(Mocha)对象装饰它
  3. 以奶泡(Whip)对象装饰它
  4. 调用cost()方法,并依赖委托将调料的价钱加上去

订单构成1
订单构成2

上面是pdf文本的截图,这个过程如果不画出来,就漏掉了很重要的循序渐进的过程。

装饰者模式:动态的将责任附加到对象上。若是要扩展功能,装饰者提供了比继承更有弹性的替代方案。

装饰者模式结构

上图是装饰者模式的结构类图。

废话不多说,看看我们的订单系统该如何写。

原始的类图中,超类Beverage基本不用改动。

public abstract class Beverage {
    String description = "";

    public String getDescription() {
        return description;
    }

    public abstract double cost();
}

下面实现调料类的抽象类,也就是装饰者类:

// 为了让CondimentDecorator 能够取代 Beverage,所有才继承Beverage
public abstract class CondimentDecorator extends Beverage {
    public abstract String getDescription();
}

下面是饮料实体类,按照上面的包装图例,我们就实现DarkRoast就好了。

public class DarkRoast extends Beverage {

    public DarkRoast() {
        description = "DarkRoast";
    }

    @Override
    public double cost() {
        return 1.99;
    }
}

下面是Mocha 和 Whip 的调料代码

public class Mocha extends CondimentDecorator {
    Beverage beverage;

    public Mocha(Beverage beverage) {
        this.beverage = beverage;
    }

    public String getDescription() {
        return beverage.getDescription() + ", Mocha";
    }

    public double cost() {
        return 0.20 + beverage.cost();
    }
}
public class Whip extends CondimentDecorator {
    Beverage beverage;

    public Whip(Beverage beverage) {
        this.beverage = beverage;
    }

    public String getDescription() {
        return beverage.getDescription() + ", Whip";
    }

    public double cost() {
        return 0.10 + beverage.cost();
    }
}

好了,依照装饰者模式,我们完成了基本的代码实现。下面是测试代码:

public class StarbuzzCoffee {
    public static void main(String[] args) {
        // 一杯DarkRoast,不需要调料
        Beverage beverage = new DarkRoast();
        System.out.println(beverage.getDescription() + " $" + beverage.cost());

        // 一杯DarkRoast,加双份Mocha和奶泡
        Beverage beverage2 = new DarkRoast();
        beverage2 = new Mocha(beverage2);
        beverage2 = new Mocha(beverage2);
        beverage2 = new Whip(beverage2);
        System.out.println(beverage2.getDescription() + " $" + beverage2.cost());
    }
}

运行结果如下:

DarkRoast $1.99
DarkRoast, Mocha, Mocha, Whip $2.49

Process finished with exit code 0

真实世界的装饰者:Java I/O

文章本来是打算简单的总结下该章节的内容,方便以后资料的查找,回忆下知道大概讲的是什么东西,写下来发现,如果不能够将这个循序渐进的过程写下来,那么就失去这本书基本的宗旨。 上面的内容基本都是章节的文本,主要是担心自己理解误导了读者。

如果对文章的内容感兴趣,不妨去读一下《Head First设计模式》。