装饰模式是一种用于替代继承的技术,它通过一种无须定义子类的方式来给对象动态增加职责,使用对象之间的关联关系取代类之间的继承关系。
概览
定义
Decorator Pattern: Attaches additional responsibility to anobject dynamically. Decorators provide a flexible alternative to subclassingfor extending functionality.
装饰模式(DecoratorPattern)在不改变原类文件以及不使用继承的情况下,动态地将责任附加到对象上,从而实现动态拓展一个对象的功能。
UML类图
参与者参与者
Component(抽象构件)
- 是一个接口或者抽象类,用来定义基本行为
- 是具体构件和抽象装饰类的共同父类,声明了在具体构件中实现的业务方法,它的引入可以使客户端以一致的方式处理未被装饰的对象以及装饰之后的对象,实现客户端的透明操作。
ConcreteComponent(具体构件)
- 抽象构件类的子类,用于定义具体的构件对象(即被装饰者)
- 实现了在抽象构件中声明的方法,装饰器可以给它增加额外的职责(方法)
Decorator(抽象装饰类)
- 一个接口或抽象类,也是抽象构件类的子类,用于给具体构件增加职责,但是具体职责在其子类中实现
- 对于ConcreteComponent来说,不需要知道Decorator的存在,
- 它维护一个指向抽象构件对象的引用,通过该引用可以调用装饰之前构件对象的方法,并通过其子类扩展该方法,以达到装饰的目的
ConcreteDecorator(具体装饰类)
- 抽象装饰类的子类,负责向构件添加新的职责
- 每一个具体装饰类都定义了一些新的行为,它可以调用在抽象装饰类中定义的方法,并可以增加新的方法用以扩充对象的行为。
- 每个装饰者都应该有一个实例变量用以保存某个Component的引用,持有Component的引用后,由于其自身也是Component的子类,相当于ConcreteDecorator包裹了Component,不但有Component的特性,同时自身也可以有别的特性,也就是所谓的装饰。
设计的原则
装饰者和被装饰者有相同超类
这里利用继承是为了达到类型匹配,而不是利用继承获得行为
因为装饰者和被装饰者是同一个类型,因此装饰者可以取代被装饰者,这样就使被装饰者拥有了装饰者独有的行为。
用组合而不是继承
利用继承设计子类,只能在编译时静态决定,并且所有子类都会继承相同的行为;利用组合的做法扩展对象,就可以在运行时动态的进行扩展。
利用装饰者,我们可以实现新的装饰者增加新的行为,而不用修改现有代码,而如果单纯依赖继承,每当需要新行为时,还得修改现有的代码。遵循了开放-关闭原则:类应该对扩展开放,对修改关闭。
调用方式
- 包裹
它是通过创建一个包装对象,也就是装饰来包裹真实的对象 - 保存被装饰者的引用
在装饰模式中引入了装饰类,在装饰类中既可以调用待装饰的原有类的方法,还可以增加新的方法,以扩充原有类的功能(在装饰者类中调用被装饰者类的方法,封装成新的功能方法) - 装饰者类拥有被装饰者类的对象,一般是当构造参数传入
一个例子
分析
一个小摊卖手抓饼和烤冷面(都是小吃)。
点了手抓饼和烤冷面之后还可以在这个基础之上增加一些配料,例如煎蛋,火腿片等,每个配料的价格都不一样。
随意搭配配料,最终价格是手抓饼和烤冷面基础价+每一种所选配料价格的总和。小摊的价格单如下:
小吃(Snack) | 价格 |
---|---|
手抓饼(Handcake) | 5 |
烤冷面(Noodles) | 7 |
配料(Condiment ) | 价格 |
---|---|
煎蛋(Friedegg) | 1 |
火腿(Ham) | 2 |
培根(Bacon) | 3 |
UML类图
用装饰者模式处理,主体是被装饰者,而配料则是装饰者,UML类图:
UML类图代码实现:
结构Snack
public abstract class Snack {
public String desc = "我不是一个具体的食物";
public String getDesc() {
return desc;
}
public abstract double cost();
}
Handcake
public class Handcake extends Snack {
public Handcake() {
desc = "手抓饼";
}
@Override
public double cost() {
return 5;
}
}
Noodles
public class Noodles extends Snack {
public Noodles() {
desc = "烤冷面";
}
@Override
public double cost() {
return 7;
}
}
Condiment
public abstract class Condiment extends Snack {
public abstract String getDesc();
}
FiredEgg
public class FiredEgg extends Condiment {
private Snack snack;// 持有Component的引用
public FiredEgg(Snack snack) {
this.snack = snack;
}
@Override
public String getDesc() {
return snack.getDesc() + ", 煎蛋";
}
@Override
public double cost() {
return snack.cost() + 1;
}
}
Ham
public class Ham extends Condiment {
private Snack snack;// 持有Component的引用
public Ham(Snack snack) {
this.snack = snack;
}
@Override
public String getDesc() {
return snack.getDesc() + ", 火腿";
}
@Override
public double cost() {
return snack.cost() + 2;
}
}
Bacon
public class Bacon extends Condiment {
private Snack snack;// 持有Component的引用
public Bacon(Snack snack) {
this.snack = snack;
}
@Override
public String getDesc() {
return snack.getDesc() + ", 培根";
}
@Override
public double cost() {
return snack.cost() + 3;
}
}
测试类:TestDecorate
public class TestDecorate {
public static void main(String[] args) {
Snack snack1 = new Handcake();
System.out.println(snack1.getDesc() + "纯手抓饼花费" + snack1.cost());
snack1 = new FiredEgg(snack1);
System.out.println(snack1.getDesc() + "手抓饼+煎蛋总共花费" + snack1.cost());
Snack snack2 = new Noodles();
System.out.println(snack2.getDesc() + "纯烤冷面花费" + snack2.cost());
snack2 = new FiredEgg(snack2);
snack2 = new Ham(snack2);
snack2 = new Bacon(snack2);
System.out.println(snack2.getDesc() + "烤冷面+煎蛋+火腿+培根总共花费" + snack2.cost());
}
}
输出
输出小结分析
Noodles、FiredEgg、Ham、Bacon都是继承自Snack 基类,但是具体实现不同:
- Noodles是Snack的直接子类,是被装饰者
- FiredEgg、Ham、Bacon是装饰者,保存了Snack的引用,实现了cost()方法,并且在cost()方法内部,不但实现了自己的逻辑,同时也调用了Snack引用的cost()方法,即获取了被装饰者的信息,这是装饰者的一个特点,保存引用的目的就是为了获取被装饰者的状态信息,以便将自身的特性加以组合。
总结
1、装饰者和被装饰者对象有相同的超类型,所以在任何需要原始对象(被装饰者)的场合,都可以用装饰过得对象代替原始对象
2、可以用一个或多个装饰者包装一个对象(被装饰者)
3、装饰者可以在所委托的装饰者行为之前或之后加上自己的行为,以达到特定的目的
4、被装饰者可以在任何时候被装饰,所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象
5、装饰者会导致出现很多小对象,如果过度使用,会让程序变得复杂
参考文章
Java设计模式之装饰者模式(Decorator pattern)
学习、探究Java设计模式——装饰者模式
设计模式学习笔记之三:装饰者模式
设计模式(结构型)之装饰者模式(Decorator Pattern)
网友评论