概述

• 装饰模式是一种用于替代继承的技术，他通过一种无需定义子类的方式来给对象动他动态增添职责，使用对象之间的关联关系，取代类之间的继承关系。
• 装饰模式：动态的给一个对象增加一些额外的职责，就扩展功能而言，装饰模式提供了一种比使用子类更加灵活的替代方案。
• 在装饰模式中引入了装饰类，在装饰类中既可以调用带装饰的原有类的方法，还可以增加新的方法以扩充原有类的功能。

结构

• Component()（抽象构件）：是具体构件和抽象装饰类的共同父类，声明了在具体构件中实现的业务方法，它的引入可以使客户端以一致的方式处理未被装饰的对象的以及装饰后的对象，实现客户端透明操作。
• ConcreteComponent()（具体构件）：他是抽象构件类的子类，用于定义具体的构件对象，实现了在抽象构件中声明的方法，装饰类还可以给他增加额外的职责（方法）。
• Decorator（抽象装饰类）:他也是抽象构件类的子类，用于给具体构件增加职责，但是具体职责在子类中实现，它维护了一个指向抽象构建对象的引用，通过该应用可以调用装饰之前构建对象的方法，并通过其子类扩展该方法以达到装饰的目的。
• ConcreteDecorator（具体装饰类）：他是抽象装饰类的子类，负责向构建添加新的职责

代码结构

• 抽象构件类

//抽象构件类
public abstract class Component {
	//在其中声明抽象业务方法，也可以有具体实现
	public abstract void operation();
}

• 具体构件类

//具体构件：实现一些简单的业务方法，一些复杂的功能需要通过装饰类来进行扩展。
public class ConcreteComponent extends Component{
	public void operation() {
		//基本功能的实现
	}
}

• 抽象装饰类

public class Decorator extends Component{
	
	//维持一个对抽象构件对象的引用
	private Component component;
	
	//注册一个抽象构件类型的对象
	public Decorator(Component component) {
		this.component=component;
	}
	
	@Override
	public void operation() {
		component.operation();//调用原有的业务方法
	}
}

• 具体装饰类

public class ConcreteDecorator extends Decorator{
	//将具体构件的对象注入其中
	public ConcreteDecorator(Component component) {
		super(component);
	}
	
	//重写父类方法
	public void operation() {
		super.operation();//调用原有业务方法
		addedBehavior();//调用新增业务方法
	}
	
	//新增业务方法
	public void addedBehavior() {	
	}
}

透明装饰模式

• 要求客户端完全针对抽象编程装饰模式的透明要求，客户端程序不应该将对象声明为具体构件类型或具体装饰类型，而应该全部声明为抽象构件类型。

半透明装饰模式

• 也就是说对于客户端而言，具体构建无需关心是透明的，但是具体装饰类必须制定，这是不透明的。

优缺点

• 优点：

1. 对于扩展一个对象的功能，装饰模式比继承更灵活，不会导致类的个数急剧增加。
2. 可以通过一种动态的方式来扩展一个对象的功能，通过配置文件可以在运行时选择不同的具体装饰类，从而实现不同的行为。
3. 可以对一个对象进行多次装饰，得到功能更加强大的对象。
4. 具体构建类和具体装饰类可以独立变化。

• 缺点：

1. 在使用装饰模式进行系统设计时，产生很多小对象，这些对象产生必然会占用更多的系统资源，一定程度上影响程序的性能。
2. 排错困难

应用场景

• 在不影响其他对象的情况下，以动态透明的方式给单个对象添加职责。
• 当不能采用继承的方式对系统进行扩展或者采用继承，不利于系统扩展和维护时，可以使用装饰模式。如final定义的类。