什么是装饰模式
装饰（ Decorator ）模式又叫做包装模式。通过一种对client透明的方式来扩展对象的功能，是继承关系的一个替换方案。装饰模式的结构
装饰模式的角色和职责
抽象组件角色： 一个抽象接口，是被装饰类和装饰类的父接口。
详细组件角色：为抽象组件的实现类。
抽象装饰角色：包括一个组件的引用。并定义了与抽象组件一致的接口。
详细装饰角色：为抽象装饰角色的实现类。负责详细的装饰。
以一个样例来解释一下，假设我们如今要想造一辆车，对 ！ 就是车， Car。
大家都知道，不同的车功能不同，有的车能够跑，废话！
有的车能够飞，有的车能够游泳，有的车能够跳跃。
。。
别激动，我就举个样例。
依照传统的面向对象的思想，我们肯定先定义一个Car的父类，在这个父类中定义一些全部车都具有的功能，比方run()，然后再派生出各种子类继承这个Car父类，然后在子类中再实现自己独特的功能。比如。我声明一个FlyCar继承自Car，然后在FlyCar中实现父类的run()。在实现自己独特的fly()方法。
你是不是这么想的。别不承认。一般人都是酱紫想的。我也是这么想的，起初我还非常自豪。由于我用到了面向对象的思想!!!
可是，假设如今我想造一个既能游泳又能飞的车怎么办？难道我定义一个FlySwimCar继承自Car，OK，当然能够。
可是，随着科技的发展。车的功能越来越丰富，你难道要不停的定义各种组合功能的车吗。你应该知道排列组合吧~~~这显然不符合程序猿偷懒的个性。
所以。就有了 装饰模式。我们边看代码，边解释。
首先。定义一个Car基类，当然，这个必须是接口，你懂的。你不可能直接new 一个Car出来吧。谁知道这个Car是具有哪个功能的Car。可是这个接口Car中应该包括最主要的车的功能。
//Car.java
public interface Car {
public void run();
// 显示车的功能
public void show();
}最普通的车只是于实现这个接口了，这个车除了能跑之外，啥都不能干。
对，这就是传说中的 【跑车】。
//RunCar.java
public 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.java
public 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.java
public 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.java
public 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.java
public 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.java
public 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()方法。