装饰者模式

 装饰器模式

动态地给一个对象添加一些额外的职责，装饰器模式就是基于对象组合的方式，可以很灵活的给对象添加所需要的功能。装饰器模式的本质就是动态组合。

装饰器模式意图和结构

装饰者模式提供了一种给类增加功能的方法，它通过动态组合可以给原有的代码新增加新的代码，达到修改现有代码的目的，因此我们可以用在修复bug上。

装饰者模式主要有Component、ConcreteComponent、Decorator和ConcreteDecorator组成。

•  抽象组件角色(Component)：定义一个对象接口，以规范准备接受附加责任的对象，即可以给这些对象动态地添加职责。
•   具体组件角色(ConcreteComponent) :被装饰者，定义一个将要被装饰增加功能的类。可以给这个类的对象添加一些职责。
•   抽象装饰器(Decorator):维持一个指向构件Component对象的实例，并定义一个与抽象组件角色Component接口一致的接口。
•   具体装饰器角色（ConcreteDecorator):向组件添加职责。

uml图

代码实例

通过一个实际的例子，借用网上的一个例子，

1，项目经理接到一个项目，项目最终要完成编码。

2，项目经理接到项目后，先做些前期的工作（比如需求分析、设计），然后将编码工作委派给代码工人，

3，代码工人干完后，项目经理做项目的收尾工作。

组件对象的接口

public interface Component { 

    void doCoding(); 
}

具体组件角色（程序员写代码）

public class ConcreteComponent implements Component{ 
    /** 
     * 程序员编码 
     */ 
    public void doCoding(){ 
        System.out.println("程序员写代码，终于编完了！"); 
    } 
}

具体装饰器接口（维持一个指向对象的接口）

public class Decorator implements Component {

	// 持有组件对象
	private Component component;

	public Decorator(Component component) {
		this.component = component;
	}

	@Override
	public void doCoding() {
		component.doCoding();
	}


	public void operation() {
		
	}

}

装饰器的具体实现，向组件对象添加职责.

ConcreteDecoratorA

public class ConcreteDecoratorA extends Decorator {

	public ConcreteDecoratorA(Component component) {
		super(component);
	}

	@Override
	public void operation() {
		super.operation();
		System.out.println("项目经理A 在做需求分析"); 
	}
}

ConcreteDecoratorB

public class ConcreteDecoratorB extends Decorator {

	public ConcreteDecoratorB(Component component) {
		super(component);
	}

	@Override
	public void operation() {
		super.operation();
		System.out.println("项目经理B 在做需求分析"); 
	}
}

客户端测试

public class DecoratorTest {
	public static void main(String[] args) {
		 // 首先创建需要被装饰的原始对象(即要被装饰的对象)
		Component c1 = new ConcreteComponent();
		// 给对象透明的增加功能A并调用
		Decorator decoratorA = new ConcreteDecoratorA(c1); 
		decoratorA.operation();
	}
}

总结

使用装饰者模式应注意以下几点：

• 接口的一致性：装饰器对象的接口必须与它所装饰的Component的接口是一致的。
• 省略抽象的Decorator模式：当仅需要添加一个职责时，没有必要定义抽象Decorator类。
• 保持Component类的简单性：为保证接口的一致性，组件和装饰必须有一个公共的Component父类，因此保持这个类的简单性是很重要的。
• 改变对象外壳与改变对象内核：装饰器就想对象的外壳，改变的是对象的行为；而当被装饰对象过于庞大和复杂时，装饰器就显得力不从心了，这时候，后面会介绍的Strategy模式可能是一个更好的选择。

在以下两种情况下可以考虑使用装饰器模式：     (1)需要在不影响其他对象的情况下，以动态、透明的方式给对象添加职责。     (2)如果不适合使用子类来进行扩展的时候，可以考虑使用装饰器模式。