思考题

有如下类设计：


如果牛奶的价钱上扬，怎么办？新增一种焦糖调料风味时，怎么办？
造成这种维护上的困难，违反了我们之前提过的哪种设计原则？ 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