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

思考题

有如下类设计:
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:idealism-xxm 《Head First 设计模式》读书笔记地址:reading-notes/head-first-design-patterns
公众号:满赋诸机
满赋诸机

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值