初学设计模式【3】装饰模式——Decorator

　　装饰模式：动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

如定义中说的那样，装饰模式可以动态的为对象添加新的职责，通过继承也能达到扩展类功能的目的。那么这两种方式的区别在哪里呢？虽然通过继承也能达到扩展功能但这种方式是在编译时静态决定的，所有子类都会继承到相同的行为，不具有弹性，应对未来变化的能力较低。而通过Decorator模式就可以在运行时动态扩展，而且被装饰对象可以自由组合新的行为，更易于应对未来的功能扩展。

设计原则：类应该对扩展开放，对修改关闭。这就是“开放关闭”原则。类应该是容易扩展的在不需要修改现有代码的情况下，这样的设计可以应对改变，而且不会引入新的bug。Decorator模式就很好的遵循了这个原则。

UML类图

　　

　　分析：ConcreteComponent代表一个被装饰对象，扩展自抽象类Component；Decorator是装饰者共同实现的接口；派生自Decorator的为具体的装饰对象；至于装饰者与被装饰者共同派生自Component是为了达到“装饰者与被装饰者”的类型匹配，因为我们用Decorator装饰了ConcreteComponent后不能改变ConcreteComponent的类型；Component不实现具体的行为，只是为了达到前面所说的装饰与被装饰者的类型匹配。

实例

　　咖啡馆下单系统：顾客可以选择咖啡的类型，还可以选择加入一种或多种调料，最后系统可以根据不同的咖啡类型及所加调料计算出总金额，打印出清单。

显然，我们用调料来装饰具体咖啡，uml图如下：

截自：《HeadFirst设计模式》

Beverage

public abstract class Beverage {
    String description = "Unknown Beverage";

    public String getDescription() {
        return description;
    }

    public abstract float cost();
}

Decaf

public class Decaf extends Beverage {

    public Decaf(String description) {
        super.description = description;
    }

    @Override
    public float cost() {
        return 1.2f;
    }

}

Espresso

public class Espresso extends Beverage {

    public Espresso(String descraption) {
        super.description = descraption;
    }

    @Override
    public float cost() {
        return 1.00f;
    }

}

CondimentDecorator

public abstract class CondimentDecorator extends Beverage {
    @Override
    public abstract String getDescription();

}

Milk

public class Milk extends CondimentDecorator {

    private Beverage beverage; // 代表被装饰对象

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

    @Override
    public String getDescription() {
        return beverage.getDescription() + "+ Milk";
    }

    @Override
    public float cost() {
        return 0.31f + beverage.cost();
    }

}

Mocha

public class Mocha extends CondimentDecorator {

    private Beverage beverage; // 代表被装饰对象

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

    @Override
    public String getDescription() {
        return beverage.getDescription() + "+ Mocha";
    }

    @Override
    public float cost() {
        return 0.11f + beverage.cost();
    }

}

 Soy

public class Soy extends CondimentDecorator {
    private Beverage beverage; // 代表被装饰对象

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

    @Override
    public String getDescription() {
        return beverage.getDescription() + "+ Soy";
    }

    @Override
    public float cost() {
        return 0.21f + beverage.cost();
    }

}

 测试

import org.junit.Test;

public class TestDecorator {

    @Test
    public void test() {
        Beverage beverage = new Decaf("Decaf");
        beverage = new Milk(beverage);
        beverage = new Milk(beverage);
        beverage = new Mocha(beverage);
        System.out.println(beverage.getDescription() + ":" + beverage.cost());
    }
}

 　　测试结果：（双倍牛奶+摩卡+无咖啡因咖啡）

 

总结

 1)装饰模式的根类Component一般为abstract或接口类型，设置此类的目的只为了达到装饰者与被装饰者类型的匹配，不实现具体的行为，这一点很重要，可以结合上面的例子仔细体会。

2)装饰模式也有缺点：会增加我们所要维护类的数量。此模式一般与“工厂模式”一起使用，可克服此问题。

3）装饰模式可以达到运行时动态扩展系统功能的目的，通过不断扩展新的具体装饰类可以提高应对未来变化的能力。

 4)java IO类就是依照这个模式设计的