Head First 设计模式 —— 03. 装饰器 (Decorator) 模式

那年仲夏 提交于 2021-01-07 00:53:54

思考题

有如下类设计: P081-星巴兹饮料基础类图
P082-星巴兹饮料详细类图
如果牛奶的价钱上扬,怎么办?新增一种焦糖调料风味时,怎么办?
造成这种维护上的困难,违反了我们之前提过的哪种设计原则? P82

  • 取出并封装变化的部分,让其他部分不收影响
  • 多用组合,少用继承

思考题

请为下面类的 cost() 方法书写代码。 P83
抽象类:Beverage

public class Beverage {
    public double cost() {
        double totalCost = 0.0;
        
        if (hasMilk()) {
            totalCost += milkCost;
        }
        if (hasSoy()) {
            totalCost += soyCost;
        }
        if (hasMocha()) {
            totalCost += mochaCost;
        }
        if (hasWhip()) {
            totalCost += whipCost;
        }
        
        return totalCost;
    }
}

具体类:DarkRoast

public class DarkRoast extends Beverage {
    public DarkRoast() {
        description = "Most Excellent Dark Roast";
    }
    
    public double cost() {
        return baseCost + super.cost();
    }
}

思考题

当哪些需求或因素改变时会影响这个设计? P84

  • 调料价钱的改变会使我们改变现有代码
  • 一旦出现新的调料,我们就需要加上新的方法,并改变超类中的 cost() 方法
  • 以后可能会开发出新饮料。对这些饮料而言(例如:冰茶),某些调料可能并不适合,但是在这个设计方式中,Tea (茶)子类仍然将继承那些不适合的方法,例如:hasWhip() (加奶泡)
  • 万一顾客想要双倍摩卡或咖啡,怎么办?
  • 调料价钱随着具体饮料而改变
  • 饮料基础价钱随着大中小被的不同而改变

设计原则

  • 开闭原则:类应该对扩展开放,对修改关闭 P86
    • 策略模式、观察者模式和装饰器模式均遵循开闭原则 P105

装饰器模式

动态地将责任附加到对象上,而不改变其原有代码。若扩展功能,装饰器提供了比继承更优弹性的替代方案。 P91 装饰器模式

特点
  • 装饰类和被装饰类有相同的超类型 P90
  • 装饰类可以在所委托的被装饰类的行为之前(或之后),加上自己的行为,以达到特定的目的 P90
  • 可以透明地插入装饰器,使用时甚至不需要知道是在和装饰器交互 P104
  • 适合用来建立有弹性的设计,维持开闭原则 P104
缺点
  • 存在大量小类,使用时将会增加代码复杂度 P101 P104
  • 使用时依赖某种特殊类型,然后忽然导入装饰器,却又没有周详地考虑一切 P104
思考题

我们在星巴兹的朋友决定开始在菜单上加上咖啡的容量大小,供顾客可以选择小贝(tall)、中杯(grande)、大杯(venti)。星巴兹认为这是任何咖啡都必须具备的,所以在 Beverage 类中加上了 getSize() 与 setSize() 。他们也希望调料根据咖啡容量收费,例如:小中大杯的咖啡加上豆浆,分别加收 0.10、0.15、0.20 美金。
如何改变装饰者类应对这一的需求? P99

public class Soy extends CondimentDecorator {
    Beverage beverage;
    
    public Soy(Beverage beverage) {
        this.beverage = beverage;
    }
    
    public int getSize() {
        return beverage.getSize();
    }
    
    public void setSize(int size) {
        beverage.setSize(size);
    }
    
    public String getDescription() {
        return beverage.getDescription() + ", Soy";
    }
    
    public double cost() {
        double soyCost = 0.0;
        
        switch (getSize()) {
            case TALL:
                soyCost = 0.10; 
                break;
            case GRANDE:
                soyCost = 0.15; 
                break;
            case VENTI:
                soyCost = 0.20; 
                break;
            default:
                soyCost = 0.0;
        }
        
        return beverage.cost() + soyCost;
    }
}

所思所想

  • 装饰器模式使用了继承(或实现接口)的方式,所以超类型增加方法时,所有子类都需要改变,设计时要充分考虑
  • 总感觉装饰器模式很熟悉,看了 java-design-patterns/decorator 后,发现装饰器模式的思想平常都是运用在 AOP 中实现的 (最后学了代理模式发现原来是动态代理模式)

本文首发于公众号:满赋诸机(点击查看原文) 开源在 GitHub :reading-notes/head-first-design-patterns


易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!