[TOC]
1. 定义
装饰器模式是指在不改变原有对象的基础上,将功能附加到对象上,提供了比继承更有弹性的替代方案(扩展原有对象的功能)
2. 适用场景
装饰者模式在我们生活中应用也比较多如给煎饼加鸡蛋;给蛋糕加上一些水果;给房子装修等,为对象扩展一些额外的职责.装饰者在代码程序中适用于以下场景:
- 用于扩展一个类的功能或给一个类添加附加职责
- 动态的给一个对象添加功能,这些功能可以再动态的撤销
来看一个这样的场景,上班族白领其实大多有睡懒觉的习惯,每天早上上班都是踩点,于是很多小伙伴为了多赖一会儿床都不吃早餐.那么,也有些小伙伴可能在上班路上碰到卖煎饼的路边摊,都会顺带一个到公司茶水间吃早餐.卖煎饼的大姐可以给你的煎饼加鸡蛋,也可以加香肠
3. 代码实现
一个小伙在上班路上看到一个卖煎饼的摊位,过去买个煎饼,需要加鸡蛋和香肠
当前的代码智能支持加鸡蛋,火腿,如果还想加生菜或其他的,只需要增加对应的装饰器就可以了,不需要对原有代码做修改
- 创建一个煎饼 BatterCake 类
/**
* 煎饼类
*/
public class BatterCake {
/**
* 煎饼信息
*/
protected String getMsg() {
return "煎饼";
}
/**
* 煎饼价格
*/
public int getPrice() {
return 5;
}
}
- 创建一个加鸡蛋的煎饼 BatterCakeWithEgg 类
public class BatterCakeWithEgg extends BatterCake {
/**
* 煎饼信息
* 加一个鸡蛋
*/
@Override
protected String getMsg() {
return super.getMsg() + " +1 个鸡蛋";
}
/**
* 煎饼价格
* 加一个鸡蛋加1块钱
*/
@Override
public int getPrice() {
return super.getPrice() + 1;
}
}
- 再创建一个既加鸡蛋又加香肠的 BatterCakeWithEggAndSausage 类:
public class BatterCakeWithEggAndSausage extends BatterCakeWithEgg {
/**
* 煎饼信息
* 加一根香肠
*/
@Override
protected String getMsg() {
return super.getMsg() + " +1 根香肠";
}
/**
* 煎饼价格
* 加一根香肠加2块钱
*/
@Override
public int getPrice() {
return super.getPrice() + 2;
}
}
- 测试代码
public class BatterCakeTest {
public static void main(String[] args) {
BatterCake batterCake = new BatterCake();
System.out.println(batterCake.getMsg() + ",总价格:" + batterCake.getPrice());
BatterCake batterCakeWithEgg = new BatterCakeWithEgg();
System.out.println(batterCakeWithEgg.getMsg() + ",总价格:" + batterCakeWithEgg.getPrice());
BatterCake batterCakeWithEggAndSausage = new BatterCakeWithEggAndSausage();
System.out.println(batterCakeWithEggAndSausage.getMsg() + ",总价格:" + batterCakeWithEggAndSausage.getPrice());
}
}
- 运行结果
煎饼,总价格:5
煎饼 +1个鸡蛋,总价格:6
煎饼 +1个鸡蛋 +1根香肠,总价格:8
运行结果没有问题.但是,如果用户需要一个加2个鸡蛋加1根香肠的煎饼,那么用我们现在的类结构是创建不出来的,也无法自动计算出价格,除非再创建一个类做定制.如果需求再变,一直加定制显然是不科学的.那么下面我们就用装饰者模式来解决上面的问题
- 首先创建一个建煎饼的抽象 BatterCake 类
/**
* 煎饼抽象类
*/
public abstract class BatterCake {
/**
* 煎饼信息
*/
protected abstract String getMsg();
/**
* 煎饼价格
*/
protected abstract int getPrice();
}
- 创建一个基本的煎饼(或者叫基础套餐)BaseBatterCake:
public class BaseBatterCake extends BatterCake {
protected String getMsg() {
return "煎饼";
}
public int getPrice() {
return 5;
}
}
- 创建一个扩展套餐的抽象装饰者 BatterCakeDecotator 类
public abstract class BatterCakeDecorator extends BatterCake {
//静态代理，委派
private BatterCake batterCake;
public BatterCakeDecorator(BatterCake batterCake) {
this.batterCake = batterCake;
}
protected abstract void doSomething();
@Override
protected String getMsg() {
return this.batterCake.getMsg();
}
@Override
protected int getPrice() {
return this.batterCake.getPrice();
}
}
- 创建鸡蛋装饰者 EggDecorator 类
public class EggDecorator extends BatterCakeDecorator {
public EggDecorator(BatterCake batterCake) {
super(batterCake);
}
protected void doSomething() {
}
@Override
protected String getMsg() {
return super.getMsg() + " +1 个鸡蛋";
}
@Override
protected int getPrice() {
return super.getPrice() + 1;
}
}
- 创建香肠装饰者 SausageDecorator 类
public class SausageDecorator extends BatterCakeDecorator {
public SausageDecorator(BatterCake batterCake) {
super(batterCake);
}
protected void doSomething() {
}
@Override
protected String getMsg() {
return super.getMsg() + " +1 根香肠";
}
@Override
protected int getPrice() {
return super.getPrice() + 2;
}
}
- 测试代码
public class BatterCakeTest {
public static void main(String[] args) {
BatterCake batterCake;
// 路边摊买一个煎饼
batterCake = new BaseBatterCake();
// 煎饼有点小，想再加一个鸡蛋
batterCake = new EggDecorator(batterCake);
// 再加一个鸡蛋
batterCake = new EggDecorator(batterCake);
// 很饿，再加根香肠
batterCake = new SausageDecorator(batterCake);
// 跟静态代理最大区别就是职责不同
// 静态代理不一定要满足 is-a 的关系
// 静态代理会做功能增强，同一个职责变得不一样
// 装饰器更多考虑是扩展
System.out.println(batterCake.getMsg() + ",总价:" + batterCake.getPrice());
}
}
- 运行结果
煎饼 +1个鸡蛋 +1个鸡蛋 +1根香肠,总价:9
为了加深印象,我们再来看一个应用场景.是否还有小伙伴记得我们上次讲个的适配器模式,为了实现新功能与老功能兼容,创建一个新的类继承已有的类,实现功能扩展,遵循开闭原则.今天我们再用装饰者模式再来升级一次代码,同时也做一个更好的对比.
装饰者模式最本质的特征是讲原有类的附加功能抽离出来,简化原有类的逻辑.通过这样两个案例,我们可以总结出来,其实抽象的装饰者是可有可无的,具体可以根据业务模型来选择
4. 装饰者模式和适配器模式对比
装饰者和适配器模式都是包装模式(WrapperPattern),装饰者也是一种特殊的代理模式
| 装饰者模式 | 适配器模式 | |
|---|---|---|
| 形式 | 是一种非常特别的适配器模式 | 没有层级关系,装饰器模式有层级关系 |
| 定义 | 装饰者和被装饰者都实现同一个接口,主要目的是为了扩展之后依旧保留 OOP 关系 | 适配器和被适配者没有必然的联系,通常是采用继承或代理的形式进行包装 |
| 关系 | 满足 is-a 的关系 | 满足 has-a 的关系 |
| 功能 | 注重覆盖,扩展 | 注重兼容,转换 |
| 设计 | 前置考虑 | 后置考虑 |
5. 在源码中的应用
5.1java.io 中 IO 流
装饰器模式在源码中也应用得非常多,在 JDK 中体现最明显的类就是 IO 相关的类,如 BufferedReader,InputStream,OutputStream,看一下常用的 InputStream 的类结构图
IO 流总结起来就是大桶套小桶
public class FilterInputStream extends InputStream {
.....
protected FilterInputStream(InputStream in) {
this.in = in;
}
}
public class BufferedInputStream extends FilterInputStream {
public BufferedInputStream(InputStream in) {
this(in, DEFAULT_BUFFER_SIZE);
}
}
5.2 Spring 中 TransactionAwareCacheDecorator
在 Spring 中的 TransactionAwareCacheDecorator 类我们也可以来尝试理解一下,这个类主要是用来处理事务缓存的,来看一下代码
public class TransactionAwareCacheDecorator implements Cache {
private final Cache targetCache;
public TransactionAwareCacheDecorator(Cache targetCache) {
Assert.notNull(targetCache, "Target Cache must not be null");
this.targetCache = targetCache;
}
...
}
TransactionAwareCacheDecorator 就是对 Cache 的一个包装.再来看一个 MVC 中的装饰者模式 HttpHeadResponseDecorator 类
public class HttpHeadResponseDecorator extends ServerHttpResponseDecorator {
public HttpHeadResponseDecorator(ServerHttpResponse delegate) {
super(delegate);
}
...
}
最后,看看 MyBatis 中的一段处理缓存的设计 org.apache.ibatis.cache.Cache 类,找到它的包定位
名字上来看其实更容易理解了.比如 FifoCache 先入先出算法的缓存;LruCache 最近最少使用的缓存;TransactionlCache 事务相关的缓存,都是采用装饰者模式.MyBatis 源码在我们后续的课程也会深入讲解,感兴趣的小伙伴可以详细看看这块的源码,也可以好好学习一下 MyBatis 的命名方式,今天我们还是把重点放到设计模式上
6. 优缺点
6.1 优点
- 装饰者是继承的有力补充,比继承灵活,不改变原有对象的情况下动态地给一个对象扩展功能,即插即用
- 通过使用不同装饰类以及这些装饰类的排列组合,可以实现不同效果
- 装饰者完全遵守开闭原则
6.2 缺点
- 会出现更多的代码,更多的类,增加程序复杂性
- 动态装饰时,多层装饰时会更复杂