学过面向对象的我们都知道，通过继承：能够重用和扩展已经被彻底测试过的代码，且无需修改之。但就像策略模式中所讲到的，继承会禁锢类的方法。那么如果要扩展功能，我们还是必须使用继承吗？
答案当然是否定的，因为设计模式中为我们提供了一个很好的模式--装饰模式：动态地将责任附加到对象上。这里所谓的动态可以简单理解为灵活。那么不使用继承，又要如何帮助我们达到目的呢？下面一起来看。
先来看一个例子，我们去咖啡店买咖啡，光咖啡类型就有不同的选择：综合、深焙、低咖啡因、浓缩。但喝咖啡可没这么简单，它还需要加入相应的配料来满足顾客口味需求：牛奶、豆浆、摩卡、奶泡。现在咖啡店要增加一些新口味和类型，那么原先使用继承的系统将不再适用，一旦增加的类型和种类增多下面的这张图就变成一坨了吧：
那么使用装饰模式应该是什么样的呢？
像上面这幅图显示的这样，我们将具体的咖啡类型和配料都作为一个类的子类，通过类型和配料的自由组合实现功能的同时实现代码的复用性，提高后期的可维护性。其代码如下：
1.抽象类
<span style="font-size:18px;">package 巴兹咖啡;
//这是一个抽象类。
public abstract class Beverage {
String description ="Unknown Beverage";
public String getDescription (){
//获取咖啡调配方法
return description;
}
public abstract double cost();
}
</span>
2.具体组件
public abstract class CondimentDecorator extends Beverage {
public abstract String getDescription();
}
public class DarkRoast extends Beverage {
public DarkRoast() {
description ="DarkRoast Coffee";
}
public double cost(){
return .99;
}
}
</span>public class Espresso extends Beverage {
public Espresso ()
{
description ="Espresso";
}
public double cost(){
return 1.99;
}
}public class HouseBlend extends Beverage {
public HouseBlend(){
description ="House Blend Coffee";
}
public double cost(){
return .89;
}
}
</span>
其他几个类和上面列举的类似，大家可以动手实现。最终会实现下面的效果：
如果店内有需求，要实现杯型大小来进行收费，那么我们可以在CondimentDecorator中添加中杯、小杯、大杯三个类，抽象类中添加方法：getSize（）对杯型进行获取，然后通过杯型、咖啡类型和配料的不同搭配来实现灵活收费。这样一来也就实现了动态的添加的同时也达到了解耦的效用。岂不是一举两得？
总结：
1.装饰模式中使用组合和委托在系统运行时对系统动态的增加功能。而该模式也就意味着我们要创建一堆的装饰者类，而它们又恰好是用来装饰组件的，比如：Mocha、Whip等四个配料都是用来装饰HouseBlend、 DarkRoast这 些咖啡类型的。
2.我们可以使用一个或者多个装饰者包装一个组件：调配出一个中杯的，加入牛奶、摩卡等的低咖啡因咖啡。
3.装饰者会导致设计中出现许多小对象，如果过度使用，程序依旧会变得复杂。也就是说，我们不能将咖啡的类型和配料的种类无限的扩张，否则系统会因为过多的咖啡种类和配料而运行缓慢甚至瘫痪。凡事遵循一个度的问题，东西再好吃也不能撑死，模式再好用也不能拖死系统。
所以说，在一定程度上，装饰者模式还是很棒的呢。
最后祝大家软考顺利，考试加油，let‘s go !!
原文地址：http://blog.csdn.net/ysc1123/article/details/39858317
