【设计模式】装饰者模式

• 一、背景
• 二、OO基础
• 三、OO设计原则
• 四、认识装饰者模式
• • 1.定义
  • 2.UML图
• 五、星巴兹咖啡店的设计
• • 1.UML图
  • 2.装饰者构造的饮料订单
  • 3.代码案例
• 六、总结
• • 1.装饰者模式遵循了的设计原则
  • 2.装饰者模式的一些要点纪要

本内容是来自书籍《Head First 设计模式》的第三章，装饰者模式（在不修改底层代码的情况可以扩展组件的功能）

1. 封装
2. 继承
3. 多态
4. 抽象

1. 封装变化，将变化的部分封装起来，与固定不变的部分分开
2. 面向接口编程，而非面向实现编程
3. 组合优于继承
4. 为交互对象之间的松耦合而努力
5. 对扩展开放，对修改关闭

装饰者模式——动态地将责任附到对象上，想要扩展功能，装饰者模式提供了有别于继承的另一种方式

使用图是后面星巴兹咖啡店设计UML图

星巴兹咖啡店的目的：想要设计出一套结算方案，用户可以点任何种咖啡，并且可以任意选择调料。

以一杯双倍摩卡豆浆奶泡拿铁咖啡为例，订单装饰流程图如下：

public abstract class Beverage {
  String description = "UNKNOWN BEVERAGE";

  public String getDescription() {
    return description;
  }

  public abstract double cost();
}
public class DarkRoast extends Beverage{

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

  @Override
  public double cost() {
    return .99;
  }
}
public class Decaf extends Beverage{

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

  @Override
  public double cost() {
    return 1.05;
  }
}
public class Espresso extends Beverage{

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

  @Override
  public double cost() {
    return 1.99;
  }
}
public class HouseBlend extends Beverage{

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

  @Override
  public double cost() {
    return .89;
  }
}
public abstract class CondimentDecorator extends Beverage{
  public abstract String getDescription();
}
public class Milk extends CondimentDecorator {
  private Beverage beverage;

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

  @Override
  public double cost() {
    return beverage.cost()+.10;
  }

  @Override
  public String getDescription() {
    return description = beverage.getDescription()+", Milk";
  }
}
public class Mocha extends CondimentDecorator{
  private Beverage beverage;

  public Mocha(Beverage beverage) {
    this.beverage = beverage;
    description = beverage.getDescription()+", mocha";
  }

  @Override
  public double cost() {
    return beverage.cost()+.20;
  }

  @Override
  public String getDescription() {
    return description = beverage.getDescription()+", whip";
  }
}
public class Soy extends CondimentDecorator{
  private Beverage beverage;

  public Soy(Beverage beverage) {
    this.beverage = beverage;
    description = beverage.getDescription()+", soy";
  }

  @Override
  public double cost() {
    return beverage.cost()+.15;
  }

  @Override
  public String getDescription() {
    return description = beverage.getDescription()+", whip";
  }
}
public class Whip extends CondimentDecorator{
  private Beverage beverage;

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

  @Override
  public double cost() {
    return beverage.cost()+.10;
  }

  @Override
  public String getDescription() {
    return description = beverage.getDescription()+", whip";
  }
}
public class Order {
  public static void main(String[] args) {
    //1.点一杯Espresso,不需要调料
    Beverage beverage = new Espresso();
    System.out.println(beverage.getDescription() + " cost : $" + beverage.cost());
    //2.点一杯DarkRoast,双倍mocha+一份whip
    Beverage beverage1 = new DarkRoast();
    beverage1 = new Mocha(beverage1);
    beverage1 = new Mocha(beverage1);
    beverage1 = new Whip(beverage1);
    System.out.println(beverage1.getDescription() + " cost : $" + beverage1.cost());
    //3.点一杯HouseBlend,一份soy+mocha+whip
    Beverage beverage2 = new HouseBlend();
    beverage2 = new Mocha(beverage2);
    beverage2 = new Soy(beverage2);
    beverage2 = new Whip(beverage2);
    System.out.println(beverage2.getDescription() + " cost : " + beverage2.cost());
  }
}

1. 组合由于继承：将组件委托给装饰者，提供在组件的基础上，扩充进一步的功能。
2. 对扩展开放，对修改关闭：起初的设计是每种咖啡对象里的cost()结算时，分别判断添加某种调料然后计算总价格，这种场景扩展性非常不好，如果此时店内突然想增加一种咖啡的调料或者某种调料卖的不好取消了，那就要去修改现有的代码。使用了观察者模式时候，我们无需修改底层代码，只需要将此调料装饰者继承CondimentDecorator，客户在点单的时候选择用它去装饰就好了。

1. 继承属于扩展形式之一，但不见得是达到弹性设计的最佳方式。
2. 在我们的设计中，应该允许行为可以被拓展，而无需修改现有的代码。
3. 组合和委托可用于在运行时动态地加上新的行为
4. 除了继承，装饰者模式也可以让我们扩展行为
5. 装饰者模式意味着一群装饰者类，这些类用来包装具体组件。
6. 装饰者类反映出被装饰的组件类型（事实上，他们具有相同的类型，都经过接口或继承实现）。
7. 装饰者可以在被装饰者的行为前面与/或后面加上自己的行为，甚至将被装饰者的行为整个取代掉，而达到特定的目的。
8. 我们可以用无数个装饰者装饰组件。
9. 装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型。
   10.装饰者会导致设计过程中出现许多小对象，如果过度使用，会让程序变得很复杂。