关于后端:Head-First-设计模式-03-装饰器-Decorator-模式

思考题

有如下类设计：


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