装饰模式

装饰模式——搭配选择

定义

动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更灵活。

UML图

如果只有一个ConcreteComponent类而没有抽象的Component类，那么Decorator可以是ConcreteComponent的一个子类。
同样，如果只有一个ConcreteDecorator类，就没有必要建立一个单独的Decorator类，可以把Decorator和ConcreteDecorator的责任合并成一个类。

用例

要求要实现一个为人穿衣服的程序，有多种种类的衣服、裤子、袜子、领带等，不要求穿戴的顺序。

使用装饰模式可以把所需的功能按正确的顺序串联起来进行控制。
by the way，不用建造者的原因是建造者模式要求过程必须是稳定的，而这里穿戴的顺序是可以任意变化的。

此例中，没有必要建立Component类，直接让服饰类Decorator继承人类ConcreteComponent。
人类（ConcreteComponent）

class Person{
	public person(){}
	private String name;
	public Person(String name){
		this.name = name;
	}
	public abstract void Show(){
		System.out.println("装扮的"+name)
	}
}

服饰类（Decorator）

class Finery : Person{
	protected Person component;
	public void decorate(Person conponent){
		this.conponent = conponent;
	}
	@Override
	public void show(){
		if(conponent != null)
			conponent.show();
	}
}

具体服饰类（ConcreteDecorator）

class TShirts : Finery{
	@Override
	public void show(){
		System.out.println("大T恤")；
		base.show();//运行原Competent的Operation()，本例中是Person类的show（）
	}
}

class BigTrouser : Finery{
	@Override
	public void show(){
		System.out.println("垮裤")；
		base.show();
	}
}

//其余类类似，省略
…………

客户端代码

public static void Main(String[] args){
	Person xc = new Person("小菜")；
	System.out.println("第一种打扮：")；
	TShirts t = new TShirts();
	BigTrouser b = new BigTrouser();
	Sneakers s = new Sneakers();
	//装饰的方法，是首先用ConcreteComponent的实例化对象c。然后用ConcreteDecoratorA的实例化对象d1来包装c，
	再让ConcreteDecoratorB的实例化对象d2来包装d1，以此类推。最终执行dn的Operation()。
	t.decorate(xc);
	b.decorate(t);
	s.decorate(b);
	//结果显示：球鞋 垮裤 T恤 装扮的小菜
	s.show();
}

UMI图——穿衣服

总结

当系统需要新功能的时候，是向旧的类中添加新的代码，这些新加的代码通常装饰了原有类的核心职责或主要行为。这些新的字段、方法或逻辑增加了主类的复杂度，只为了满足一些在特定情况下才会执行的特殊行为的需要。
考虑使用装饰模式，可以为已有功能添加更多功能的一种方式。将每个要装饰的功能放在单独的类中，并让这个类包装它所要装饰的对象，当客户有需要时可以有选择地、按顺序的使用装饰功能包装对象。有效的把类的核心职责和装饰功能区分开了，可以去除相关类中重复的装饰逻辑。