装饰者模式

动机：

“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀（多继承）。

如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响降为最低？

意图：

动态地给一个对象添加一些额外的职责（功能）。

结构：

角色：

Component：给出一个抽象接口，可以给对象动态添加职责。

ConcreteComponent：定义一个将要接收附加责任的类。

Decorator：维持一个指向Component对象的指针，并定义一个与Component接口一致的接口。

Concrete Decorator：负责给构件对象“贴上”附加的责任。

装饰模式的特点：

1、装饰者和被装饰者对象有相同的基类。

2、可以用一个或多个装饰者包装一个对象。

3、在任何需要原始对象（被包装的）的场合，可以用装饰过的对象代替它。

4、装饰者可以在所委托被装饰者的行为之前或之后，加上自己的行为，以达到特定的目的。

5、对象可以在任何时候被装饰，所以可以在运行时动态的、不限量的用装饰者来装饰对象。

装饰模式的优点：

1、从扩展对象的功能来看，装饰模式可以提供比继承更多的灵活性。

2、可以通过一种动态的方式来扩展一个对象的功能。

3、通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合，得到功能更为强大的对象。

4、具体构件类与具体装饰类可以独立变化，用户可以根据需要增加新的具体构件类和具体装饰类，在使用时再对其进行组合，原有代码无须改变，符合“开闭原则”。

装饰模式的缺点：

1、使用装饰模式进行系统设计时将产生很多小对象，这些对象的区别在于它们之间相互连接的方式有所不同，而不是它们的类或者属性值有所不同，同时还将产生很多具体装饰类。这些装饰类和小对象的产生将增加系统的复杂度，加大学习与理解的难度。

2、这种比继承更加灵活机动的特性，也同时意味着装饰模式比继承更加易于出错，排错也很困难，对于多次装饰的对象，调试时寻找错误可能需要逐级排查，较为烦琐。

适用范围：

1、在不影响其他对象的情况下，以动态、透明的方式给单个对象添加功能，或给一个类增加附加责任。

2、需要动态的给一个对象增加功能，这些功能可以再动态地撤销。

3、不能采用生成子类的方法进行扩充时：

①可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长；

②因为类定义被隐藏或类定义不能用于生成子类 （如final类）

Decorator模式的要点：

1、通过采用组合、而非继承的手法，实现了在运行时动态地扩展对象功能的能力，而且可以根据需要扩展多个功能，避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。

2、Component类在Decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且Decorator类对于Component类应该透明——即Component无需知道Decorator类，Decorator类是从外部来扩展Component类的功能。

3、Decorator类在接口上表现为is-a Component的继承关系，但在实现上又表现为has-a Component的组合关系。可以使用一个或者多个Decorator对象来“装饰”一个Component对象，且装饰后的对象仍然是一个Component对象。

4、Decorator模式并非解决“多子类衍生的多继承”问题，其应用要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

模式示例：手机来电提示

一部手机，在其接受到来电的时候，会发出声音来提醒主人。现在我们需要为该手机添加一项功能，在接收来电的时候，产生震动，为令其更加高级，不仅发声，而且振动，而且有灯光闪烁。用程序模拟实现该场景，说明所采用的设计模式，并给出类关系图。

用Java程序模拟该场景：

/**
 * 抽象构件类
 * @author ZF
 * 2015年4月6日 上午11:20:06
 */
public interface IPhone {

	public void ReceiveCall();
}

/**
 * 具体构件类
 * @author ZF
 * 2015年4月6日 上午11:20:48
 */
public class BasePhone implements IPhone{

	/* (non-Javadoc)
	 * @see com.huaxin.decorate.IPhone#ReceiveCall()
	 */
	@Override
	public void ReceiveCall() {
		System.out.println("Ring...");
	}

}

/**
 * 抽象装饰类
 * @author ZF
 * 2015年4月6日 上午11:22:15
 */
public abstract class PhoneDecorator implements IPhone{

	private IPhone phone = null;

	public PhoneDecorator(IPhone phone) {
		if(phone != null){
			this.phone = phone;
		}else{
			this.phone = new BasePhone();
		}
		
	}

	public void ReceiveCall() {
		phone.ReceiveCall();
	}
	
	
}

/**
 * 具体装饰类1
 * @author ZF
 * 2015年4月6日 上午11:40:18
 */
public class JarPhone extends PhoneDecorator{

	public JarPhone(IPhone phone) {
		super(phone);
	}

	@Override
	public void ReceiveCall() {
		super.ReceiveCall();
		System.out.println("Jar...");
	}

	
}

/**
 * 具体装饰类2
 * @author ZF
 * 2015年4月6日 上午11:55:21
 */
public class ComplexPhone extends PhoneDecorator{

	public ComplexPhone(IPhone phone) {
		super(phone);
	}

	@Override
	public void ReceiveCall() {
		super.ReceiveCall();
		System.out.println("Wink...");
	}

}

/**
 * 装饰者模式测试类
 * @author ZF
 * 2015年4月6日 上午10:30:29
 */
public class Test {
	public static void main(String[] args) {
		BasePhone phone = new BasePhone();
		phone.ReceiveCall();
		System.out.println("---------------------");
		
		JarPhone p1 = new JarPhone(phone);
		p1.ReceiveCall();
		System.out.println("---------------------");
		
		ComplexPhone p2 = new ComplexPhone(p1);
		p2.ReceiveCall();
	}
}

运行结果：

Ring...
---------------------
Ring...
Jar...
---------------------
Ring...
Jar...
Wink...

类图：