学过面向对象的我们都知道。通过继承：可以重用和扩展已经被彻底測试过的代码，且无需改动之。但就像策略模式中所讲到的，继承会禁锢类的方法。那么假设要扩展功能。我们还是必须使用继承吗？

              答案当然是否定的，由于设计模式中为我们提供了一个非常好的模式--装饰模式：动态地将责任附加到对象上。这里所谓的动态能够简单理解为灵活。那么不使用继承。又要怎样帮助我们达到目的呢？以下一起来看。

             先来看一个样例，我们去咖啡店买咖啡，光咖啡类型就有不同的选择：综合、深焙、低咖啡因、浓缩。但喝咖啡可没这么简单，它还须要添加对应的配料来满足顾客口味需求：牛奶、豆浆、摩卡、奶泡。如今咖啡店要添加一些新口味和类型，那么原先使用继承的系统将不再适用，一旦添加的类型和种类增多以下的这张图就变成一坨了吧：

         那么使用装饰模式应该是什么样的呢？

            像上面这幅图显示的这样。我们将详细的咖啡类型和配料都作为一个类的子类，通过类型和配料的自由组合实现功能的同一时候实现代码的复用性，提高后期的可维护性。其代码例如以下： 

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 !!