出来混也许是需要装的，写代码也许是需要装饰模式的

虽然我在写代码，其实我是广告man

作为一个大学学广告的，虽然毕业之后，背叛了广告，进入了码农的行业，但是做人岂能忘本，我还是喜欢广告的，说着说着，忽然想起了多年前的赵薇代言的一则洗发水广告：“人靠衣装，美靠靓妆”，经典啊，太TM经典了，要不是这句广告语的启蒙，我也许都不知道穿衣服呢？？？我也许都不知道洗头发呢？？？

笑过之后，我们回归正经吧！

其实上面的广告，要给我们讲的一个道理，或许就是：人还是需要包装的！人如此，代码呢？

答案是：代码也是需要装饰的！如何装饰呢？答案就是我们本文要讨论的Java设计模式之装饰模式！

 

老习惯，扫描《Java的模式》一书，get装饰模式的定义：

装饰模式又名包装(Wrapper)模式。装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。

 

坚持不懈，老习惯，用代码写一个实例拆解拆解装饰模式：

抽象构件(Component)角色：给出一个抽象接口，以规范准备接收附加责任的对象。

public interface Decoration {
public void makeUp();
}

具体构件(ConcreteComponent)角色：定义一个将要接收附加责任的类，并实现抽象构件角色。

public class ShampooDecoration implements Decoration{

public void makeUp() {
//你想要的业务代码！
}
}

装饰(Decorator)角色：持有一个构件(Component)对象的实例，并实现抽象构件接口。

public class ClothesDecoration implements Decoration{
private Decoration decoration;

public ClothesDecoration(Decoration decoration){
this.decoration=decoration;
}

public void makeUp() {
//业务代码
}
}

具体装饰(ConcreteDecorator)角色：负责给构件对象“贴上”附加的业务代码。

public class BeautifulGirl extends ClothesDecoration{

public BeautifulGirl(Decoration decoration) {
super(decoration);
}

public void makeUp(){
//添加相关业务代码
super.makeUp();
//添加相关业务代码
}
}

学而不思则罔：装饰模式应用场景素描

优点：装饰模式与继承关系的目的都是要扩展对象的功能，但是两者也有一定的区别。装饰模式具有更多灵活性，允许系统动态决定“贴上”一个需要的“装饰”，或者除掉一个不需要的“装饰”。继承关系则不同，继承关系是静态的，它在系统运行前就决定了。

运用我们的创意思维，通过使用不同的具体装饰类以及这些装饰类的排列组合，代码设计师可以创造出很多不同行为的组合。

缺点：还是来一个装饰模式与继承关系的比较：使用装饰模式，可以比使用继承关系需要较少数目的类，使用较少的类，当然使设计比较易于进行。但是，使用装饰模式会产生比使用继承关系更多的对象，更多的对象会使得查错变得困难，特别是这些对象看上去都很像从韩国整容回来的美女的时候。

 

夜空中最亮的启明星：

学无止境，如果想更加深入的研究和学习装饰模式及其具体应用场景，可以给大家推荐一篇文章：

Java I/O库中设计模式的应用：

http://my.oschina.net/gao0516/blog/136103?fromerr=vruhj4TV