设计模式(7)之装饰模式

1. 什么是装饰模式
   装饰（ Decorator ）模式又叫做包装模式。通过一种对客户端透明的方式来扩展对象的功能，是继承关系的一个替换方案。

2. 装饰模式的结构
   

3. 装饰模式的角色和职责

   抽象组件角色： 一个抽象接口，是被装饰类和装饰类的父接口。
   具体组件角色：为抽象组件的实现类。
   抽象装饰角色：包含一个组件的引用，并定义了与抽象组件一致的接口。
   具体装饰角色：为抽象装饰角色的实现类。负责具体的装饰。

以一个例子来解释一下，如果我们现在要想造一辆车，对 ！ 就是车， Car。

大家都知道，不同的车功能不同，有的车可以跑，废话！有的车可以飞，有的车可以游泳，有的车可以跳跃。。。别激动，我就举个例子。

按照传统的面向对象的思想，我们肯定先定义一个Car的父类，在这个父类中定义一些所有车都具有的功能，比如run()，然后再派生出各种子类继承这个Car父类，然后在子类中再实现自己独特的功能。例如，我声明一个FlyCar继承自Car，然后在FlyCar中实现父类的run()，在实现自己独特的fly()方法。你是不是这么想的，别不承认，一般人都是酱紫想的。我也是这么想的，起初我还很自豪，因为我用到了面向对象的思想!!!

但是，如果现在我想造一个既能游泳又能飞的车怎么办？难道我定义一个FlySwimCar继承自Car，OK，当然可以。但是，随着科技的发展，车的功能越来越丰富，你难道要不停的定义各种组合功能的车吗，你应该知道排列组合吧~~~这显然不符合程序员偷懒的个性。

所以，就有了 装饰模式。我们边看代码，边解释。

首先，定义一个Car基类，当然，这个必须是接口，你懂的，你不可能直接new 一个Car出来吧，谁知道这个Car是具有哪个功能的Car。但是这个接口Car中应该包含最基本的车的功能。

//Car.javapublic interface Car {    public void run();    // 显示车的功能    public void show();}

最普通的车不过于实现这个接口了，这个车除了能跑之外，啥都不能干。对，这就是传说中的 【跑车】。

//RunCar.javapublic class RunCar implements Car{    @Override    public void run() {        System.out.println("run...");    }    @Override    public void show() {        this.run();    }}

然后，我想造一辆能Fly的车，怎么办？

我们先定义一个抽象类CarDecorator，这个类干嘛的呢？就是对车进行包装，为啥是抽象的呢？因为你造一个能Fly的车和造一个能Swim的车，用的材料啥的肯定都不同吧，也就是说包装的内容都不同吧，所以，这个CarDecorator中定义的是包装类共有操作。就好比，把一辆普通的车改造之前，不论你是改装成能Fly的车还是能Swim的车，你首先是不是获得这个普通的车，获得普通车这个操作就是在CarDecorator基类中定义的。

//CarDecorator.javapublic abstract class CarDecorator {    private Car car;    public CarDecorator(Car car) {        this.car = car;    }    //提供方法获取包装之前的Car    //为什么要获取包装之前的Car，废话，不获得之前的Car，你怎么添加新的功能？    //那么添加功能的方法在哪？我怎么没瞅见，别急呀，往下看，肯定是特定的装饰者添加特定的功能呀。    public Car getCar() {        return car;    }    public void setCar(Car car) {        this.car = car;    }    //为了显示车具有的功能，定以了这个show()方法    public abstract void show();}

好了，现在我们就可以造能飞的车了。

//FlyCarDecorator.javapublic class FlyCarDecorator extends CarDecorator {    public FlyCarDecorator(Car car) {        super(car);    }    @Override    //显示车的功能    public void show() {        //先显示原始车的功能，这下知道为啥在CarDecorator中获得改造之前的车了吧。        this.getCar().show();        this.fly();//添加新的功能    }    public void fly(){        System.out.println("fly...");    }}

同理，我们可以造一个能Swim的车子。

//SwimCarDecorator.javapublic class SwimCarDecorator extends CarDecorator{    public SwimCarDecorator(Car car) {        super(car);    }    @Override    public void show() {        this.getCar().show();        this.swim();    }    public void swim(){        System.out.println("swim...");    }}

酱紫的话，主函数就会变得很清爽。

//MainClass.javapublic class MainClass {    public static void main(String[] args) {        Car car = new RunCar();        car.show();        System.out.println("--------------------");        SwimCarDecorator swimCar = new SwimCarDecorator(car);        swimCar.show();        System.out.println("--------------------");        FlyCarDecorator flyCar = new FlyCarDecorator(car);        flyCar.show();        System.out.println("--------------------");    }}

运行结果：

run...--------------------run...swim...--------------------run...fly...--------------------

呵呵呵，是不是很清爽。但是你有木有发现一个问题，你说造一个能Fly能Swim的车，现在却只造了一个能run和Siwm，能run和Fly的车，还要不要脸了。。。

各位看官，别激动！！！马上造。马上造。

正常人的思维是不是酱紫的，我有一个car，只能run，跑车嘛！！！现在改造(装饰)一下，能游泳了，然后我希望既能游泳也能飞，怎么办？废话，当然是把能游泳的车加一个翅膀啥的。是不是？嗯，这次你想对了。我也是怎么想的。

现在我们改我们的main函数：

//MainClass.javapublic class MainClass {    public static void main(String[] args) {        Car car = new RunCar();        car.show();        System.out.println("--------------------");        //1        Car swimCar = new SwimCarDecorator(car);        swimCar.show();        System.out.println("--------------------");        //2                                3           Car flyCar = new FlyCarDecorator(swimCar);        flyCar.show();        System.out.println("--------------------");    }}

改了三处，和原来的main函数比较下，看见没有。为什么这么改，你们不都是怎么想的吗？？？忘了？往上看看。

为了适应main函数这么改，我们修改其他的文件呢。我们看一下：

Car flyCar = new FlyCarDecorator(swimCar);

原来FlyCarDecorator的构造方法中传递的是Car，你现在传递的是swimCar，swimCar在没改之前是啥类型来着，对，是SwimCarDecorator类型。辣么，你现在知道怎么改了吧。

我们让CarDecorator实现Car接口不就完了吗？

然后分别在FlyDecorator中实现Car中没有实现的run方法

好了，代码应该不报错了吧。。。

现在看下运行结果：

怎么样，我没食言吧，说给你造个能fly能swim的就给你造了。关键代码写得还是辣么的优雅！！！嘿嘿嘿，代码不是我写的，我只是分析下。

但是，有人可能会问，你说改这就改这，说改那就改那，到底改的合不合理呢？唉，你别说，这么一改，比之前还真的合理。

首先，是main方法中的调用逻辑，之前已经说过了，这肯定是符合大多人的思考习惯的。

然后，我们看下CarDecorator实现Car接口合不合理，我们看他的子类FlyDecorator，他继承自CarDecorator，CarDecorator实现了Car接口，所以，FlyDecorator要实现Car中的接口，Car中有两个方法一个是show()和run()，show()方法在CarDecorator中已经定义为抽象方法了，已经被FlyDecorator实现了，现在就剩下run()方法没有实现了，所以，FlyDecorator要实现run()方法，你想想，FlyDecorator实现run方法合理吗？？？我觉得非常合理，你给车装个翅膀让他飞，他就不能跑了？或许人家跑的更快了呢，或许人家跑的姿势更优雅了呢？所以你也得给FlyDecorator改造车的同时修改原有功能的机会，是不是？所以我觉得很合理。同理，SwimCarsDecorator中的也要实现Car接口中的run()方法。