原文地址:https://www.cnblogs.com/yxlaisj/p/10446504.html
装饰器模式
实际上Java提供的工具包中,IO相关工具就普遍大量使用了装饰器模式,例如充当装饰功能的IO类如BufferedInputStream等,又被称为高级流,通常将基本流作为高级流构造器的参数传入,将其作为高级流的一个关联对象,从而对其功能进行扩展和装饰。
装饰器模式(Decorator Pattern),动态地给一个对象添加一些额外的职责,就增加功能来说,装饰器模式比生成子类更灵活。 ----《大话设计模式》
装饰器模式使用分层对象,动态透明地对单个对象添加职责。 下面是装饰器模式的UML类图:
装饰器实现修饰对象(Component)的接口,所有请求都转发给它处理,在转发请求之前/之后增加额外功能。使用步骤是:
用一个Decorator实现/继承需要修饰的对象Component;
在Decorator中增加一个Component的引用;
在Decorator的构造器中,增加一个Component参数来初始化Component;
在Decorator类中,使用Component的引用,将所有请求转发至Component的相应方法;
ConcreteDecorator中所有Override自Component的方法做相应调整。
从类图上看,装饰器模式与代理模式很像,是它们的目的不同,所以使用方法和适用场景上也就不同 ,装饰器模式与代理模式的区别:
代理模式专注于对被代理对象的访问;
装饰器模式专注于对被装饰对象附加额外功能。
就像前面所说的io工具包,我用BufferedInputStream和用FileInputStream去read一个文件实际使用方式上是一样的,能用FileInputStream.read(),就能用BufferedInputStream.read(),只不过,BufferedInputStream把FileInputStream包装了一下,增加了一个缓存,并不控制底层FileInputStream的read()行为。
适用场景
运行时,你需要动态地为对象增加额外职责时;
当你需要一个能够代替子类的类,借助它提供额外方法时。
代码实现
假设我去买咖啡,首先服务员给我冲了一杯原味咖啡,我希望服务员给我加些牛奶和白糖混合入原味咖啡中。使用装饰器模式就可以解决这个问题。
咖啡接口,定义了获取花费和配料的接口。
/**
* 咖啡
*/
interface Coffee {
/** 获取价格 */
double getCost();
/** 获取配料 */
String getIngredients();
}
原味咖啡,实现Coffe接口,花费1元,配料中,只有咖啡
/**
* 原味咖啡
*/
class SimpleCoffee implements Coffee {
@Override
public double getCost() {
return 1;
}
@Override
public String getIngredients() {
return "Coffee";
}
}
咖啡对象的装饰器类,同样实现Coffee接口,定义一个Coffe对象的引用,在构造器中进行初始化。并且将getCost()和getIntegredients()方法转发给被装饰对象。
/**
* 咖啡的"装饰器",可以给咖啡添加各种"配料"
*/
abstract class CoffeeDecorator implements Coffee {
protected final Coffee decoratedCoffee;
/**
* 在构造方法中,初始化咖啡对象的引用
*/
public CoffeeDecorator(Coffee coffee) {
decoratedCoffee = coffee;
}
/**
* 装饰器父类中直接转发"请求"至引用对象
*/
public double getCost() {
return decoratedCoffee.getCost();
}
public String getIngredients() {
return decoratedCoffee.getIngredients();
}
}
具体的装饰器类,负责往咖啡中“添加”牛奶,注意看getCost()方法和getIngredients()方法,可以在转发请求之前或者之后,增加功能。如果是代理模式,这里的结构就有所不同,通常代理模式根据运行时的条件来判断是否转发请求。
/**
* 此装饰类混合"牛奶"到原味咖啡中
*/
class WithMilk extends CoffeeDecorator {
public WithMilk(Coffee coffee) {
super(coffee);
}
@Override
public double getCost() {
double additionalCost = 0.5;
return super.getCost() + additionalCost;
}
@Override
public String getIngredients() {
String additionalIngredient = "milk";
return super.getIngredients() + ", " + additionalIngredient;
}
}
另一个具体装饰器类,用来给咖啡加糖,一样的逻辑。
class WithSugar extends CoffeeDecorator {
public WithSugar(Coffee coffee) {
super(coffee);
}
@Override
public double getCost() {
return super.getCost() + 1;
}
@Override
public String getIngredients() {
return super.getIngredients() + ", Sugar";
}
}
客户端使用装饰器模式,是不是与java中的io使用方式很像?
public class DecoratorDemo {
static void print(Coffee c) {
System.out.println("花费了: " + c.getCost());
System.out.println("配料: " + c.getIngredients());
System.out.println("============");
}
public static void main(String[] args) {
//原味咖啡
Coffee c = new SimpleCoffee();
print(c);
//增加牛奶的咖啡
c = new WithMilk(c);
print(c);
//再加一点糖
c = new WithSugar(c);
print(c);
}
}
输出结果:
花费了: 1.0
配料: Coffee
============
花费了: 1.5
配料: Coffee, milk
============
花费了: 2.5
配料: Coffee, milk, Sugar
============
总结
从上个例子可以看出,装饰器模式的结构很像代理模式,装饰器模式的请求转发过程很像职责炼模式,只不过:
职责链模式在转发请求过程中,最多只有一个对象会处理请求,而装饰器模式则有多个对象处一个请求。
装饰器模式是代替增加子类的一种解决方案,体现了聚合/合成复用原则的思想,尽量使用组合的方式来扩展功能,这样就把基本功能和扩展功能解耦了,使得代码可复用,可维护,灵活。关键点在于装饰器模式可以动态地为对象增加扩展功能。