学过面向对象的我们都知道。通过继承：可以重用和扩展已经被彻底測试过的代码，且无需改动之。但就像策略模式中所讲到的，继承会禁锢类的方法。那么假设要扩展功能。我们还是必须使用继承吗？
答案当然是否定的，由于设计模式中为我们提供了一个非常好的模式--装饰模式：动态地将责任附加到对象上。这里所谓的动态能够简单理解为灵活。那么不使用继承。又要怎样帮助我们达到目的呢？以下一起来看。
先来看一个样例，我们去咖啡店买咖啡，光咖啡类型就有不同的选择：综合、深焙、低咖啡因、浓缩。但喝咖啡可没这么简单，它还须要添加对应的配料来满足顾客口味需求：牛奶、豆浆、摩卡、奶泡。如今咖啡店要添加一些新口味和类型，那么原先使用继承的系统将不再适用，一旦添加的类型和种类增多以下的这张图就变成一坨了吧：
那么使用装饰模式应该是什么样的呢？
像上面这幅图显示的这样。我们将详细的咖啡类型和配料都作为一个类的子类，通过类型和配料的自由组合实现功能的同一时候实现代码的复用性，提高后期的可维护性。其代码例如以下：
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 !!
