设计模式学习笔记——装饰模式

 

Decorator 装饰模式

又被称为包裹模式Wrap

●以对客户透明的方式动态给一个对象附加更多的责任，客户端不会感觉装饰前后对象有何不同。

●装饰模式可以在不使用创造更多子类的情狂下，将对象的功能加以扩展。

 

装饰模式的对象图是呈链状结构的

比较懒 依旧盗版过来一张类图：

 

下面是代码，来看看他们都是如何构建的：

首先是Component 他是一个抽象接口，以规范准备接受附加责任的对象

 

 

public interface Component {
	void sampleOperation();
}

 

之后是ConcreteComponent 这是具体构件角色，定义了一个将要接受附加责任的类

 

public class ConcreteComponent implements Component{
	public ConcreteComponent(){
		
	}
	public void sampleOperation(){
		System.out.println("ConcreteComponent Operation");
	}
}

 

关键的Decorator角色 他持有一个Component对象的实例，并定义一个于抽象构件接口一致的接口

 

public class Decorator implements Component{
	private Component component;
	public Decorator(Component component){
		this.component=component;
	}
	public void sampleOperation(){
		component.sampleOperation();
	}
}

最后当然是具体的装饰部分了 负责给构建添加各自的附加责任 这里只其中一个addOperate

 

public class ConcreteDecorator extends Decorator{
	public ConcreteDecorator(Component component){
		super(component);
	}
	public void sampleOperation(){
		addOperation();
		super.sampleOperation();
	}

	private void addOperation(){
		System.out.println("addOperation");
	} 
}

 

最后的结果：

 

public class DecoratorDesignPattern {
	public static void main(String[] args){
		Component component = new ConcreteComponent();
		component.sampleOperation();
		Component component2 = new ConcreteDecorator(component);
		component2.sampleOperation();
	}
}

 

输出：

ConcreteComponent Operation

addOperation

ConcreteComponent Operation

 

很明显component2仍然是Component对象 所以可以无限的嵌套。。。

 

使用装饰模式的情况：

1 需要扩展一个类的功能，或者给一个类增加附加责任

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

3 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实

 

装饰模式的优缺点：

1 装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供更多的灵活性

2 通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合

3 装饰模式比继承更加容易出错

4 装饰模式相比继承产生较少的类，但同时生成更多的对象 并且这些对象看上去都比较相似

 

简化装饰模式

1 装饰类接口必须与被装饰类接口相容（ConcreteDecorator类必须继承自同一父类Component）

2 尽量保持Conponent作为一个“轻”类（可以是接口 也可以是抽象类 具体类）

3 若没有Component抽象类 只有ConcreteConponent 则Decorator类通常可以是其子类

4 若ConcreteDecorator类数目比较多，就有使用一个单独Decorator类来区分抽象和具体职责的必要，肉则可以将Decorator和ConcreteDecorator合并

 

注意，应该声明的是一个Component类型的变量（对客户端是透明的 看起来完全一样 而不是具体的ConcreteComponent）

大多数情况是半透明的装饰模式 介于装饰模式和适配器之间

 

装饰模式与其他模式的对比

装饰模式和适配器模式

装饰模式——保持端口，增强所考虑对象的性能

适配器模式——改变所考虑对象的接口，而不一定改变对象的性能

 

装饰模式和策略模式

装饰模式——表皮换掉，保持内心 要求Component尽量轻

策略模式——保持接口不变，使具体算法可以互换 抽象策略类尽量重

 

装饰模式和合成模式

装饰模式常常用于合成模式的行为扩展上，是集成的替代方案。

 

Java中的IO部分中存在大量适配器模式和装饰模式