设计模式——装饰者模式

设计模式——装饰者模式

我们的生活就是一个装饰者模式。核心就是我们自己，穿上工作服就是一个工作者，穿上围裙就是一个好丈夫。。。

1.情景举例

最近公司承接了一个项目，为一个煎饼店制作一套自助点餐系统。现在你负责设计煎饼店产品列表。首先需要一个所有煎饼的父类。

public abstract class Pancakes {

    //煎饼的名称
    String name;

    public abstract String displayName();
}

其中只有一个属性就是煎饼的具体名称，一个抽象方法返回这个煎饼的具体名称。

目前店中能做出好吃的鸡蛋煎饼，杂粮煎饼，因此我们继承Pancakes类创建了两个煎饼类。

public class EggPancakes extends Pancakes {
    //鸡蛋煎饼
    public EggPancakes() {
        name = "EggPancakes";
    }

    @Override
    public String displayName() {
        return name;
    }
}

public class GrainsPancakes extends Pancakes {
    //杂粮煎饼
    public GrainsPancakes() {
        name = "GrainsPancakes";
    }

    @Override
    public String displayName() {
        return name;
    }
}

每个具体的煎饼类都继承自Pancakes，实现了displayName()方法。做到这一步一切顺利。然后麻烦事来了，制作煎饼时需要按照顾客需要加入酱料，比如有些人爱吃辣，他们希望煎饼多加辣酱，比如有些人爱吃番茄酱，他们希望煎饼多加番茄酱。这么把酱料设计到煎饼的继承体系中呢？

2.使用装饰者模式

可以使用继承，新创建一个ChiliEggPancakes（辣酱鸡蛋煎饼）继承自EggPancakes。这个想法能解决问题，但是其他的问题也接踵而至。首先是"类爆炸“问题，按照这样的继承写法继续编写代码，会产生很多的类。

当以后新添加酱料时，就要增加更多的类，这无疑增加了维护的难度。所以我们要用装饰者模式替代传统继承。

装饰者模式的一大特点就是变继承为组合，让各种煎饼和酱料进行组合以得到理想的煎饼。

首先我们要有一个组件父类，每个组件（这里指酱料）都继承这个父类，而这个父类要继承自Pancakes类，这样做是为了获得Pancakes类的所有动作，并且以后通过多态使用这些酱料类。

public abstract class PancakesComponent extends Pancakes{
    //被装饰的煎饼类
    Pancakes pancakes;

    public PancakesComponent(Pancakes pancakes) {
        this.pancakes = pancakes;
    }

}

 其中新增一个Pancakes变量表示要装饰的对象。之后在实现各个组件（酱料）类。

//辣椒酱煎饼
public class ChiliPancakes extends PancakesComponent {

    public ChiliPancakes(Pancakes pancakes) {
        super(pancakes);
    }

    @Override
    public String displayName() {
        return "Chili" + pancakes.displayName();
    }
}

//番茄酱煎饼
public class TomatoPancakes extends PancakesComponent {

    public TomatoPancakes(Pancakes pancakes) {
        super(pancakes);
    }

    @Override
    public String displayName() {
        return "Tomato" + pancakes.displayName();
    }
}

目前只有两个酱料，所以就生成两个装饰类，他们都继承自统一的装饰组件父类（PancakesComponent）。并且在重新displayName()方法时对Pancakse类型的变量的displayName()方法进行增强，这个操作就是一个对原有类的装饰的过程。当任何的煎饼作为TomatoPancakes的被装饰者时，它都会变成一个刷上番茄酱的煎饼，因为TomatoPancakes类对他进行了装饰。

下面进行一个测试

public class MainTest {
    public static void main(String[] args) {
        //先来一份多辣鸡蛋煎饼
        Pancakes p = new ChiliPancakes(new EggPancakes());
        System.out.println("多辣鸡蛋煎饼 ：" + p.displayName());

        //再来一份多辣多番茄酱的杂粮煎饼
        Pancakes p2 = new TomatoPancakes(new ChiliPancakes(new GrainsPancakes()));
        System.out.println("多辣多番茄酱的杂粮煎饼 ：" + p2.displayName());
    }
}

通过对象之间的相互嵌套组合我们完成了装饰者模式，也解决了酱料与煎饼的兼容关系。

3.装饰者模式小结

通过使用装饰者模式，我们完美解决了上述问题。

首先我们要聊一下装饰者最大的特点：化继承为组合。继承是面向对象编程语言的一个特色，但在很多情急下它并不是最好的选择，因为继承在编译期就把代码的属性给写死了，是我们无法灵活的在运行期对继承体系进行调整和高校使用。

使用组合代替继承，通过继承父类获得动作信息，通过把对象内置到类中获得这个对象信息。由于变量是可以更换的，所以组合的复用性比继承更大。就如上面的例子，我们只需要有一个辣酱组件类，通过更换辣酱类中的Pnacakes类型变量就可以更换需要被装饰的对象，这是继承难以做到的。

装饰者模式还完美的展现了对修改关闭，对拓展开放的原则，我们没有更改被装饰对象的任何代码，只是通过在方法中调用被装饰对象的方法并进行增强。这样大大提高了代码的可维护性。

装饰者模式也有它的缺点，如果我们的代码中有依靠类名进行编码的情况就不太适合用装饰者模式。因为在装饰的过程中，类的名称会发生各种各样的变化。举个例子：例如例子我们需要既刷辣酱还刷番茄酱的煎饼，在编码时规定最后如果这个类的名称如果是TomatoPancakes时就进行后续动作。但是在装饰者模式中完成辣酱番茄酱煎饼的最终类还可能是ChiliPancakes类，因此这是装饰者模式的一个弊端：类的反复嵌套导致类名的不确定。

在编码中如果多个子类要进行若干个类型的交叉加强（即发生类爆炸）就使用装饰者模式吧。而且针对不同的情形对装饰者模式做出改动以获得最适合你代码的”装饰者模式”