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

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

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

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

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

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

扩展功能==继承？