装饰者模式
装饰器模式(Decorator Pattern)允许向一个现有的对象添加新的功能,同时又不改变其结构。这种类型的设计模式属于结构型模式,它是作为现有的类的一个包装。
这种模式创建了一个装饰类,用来包装原有的类,并在保持类方法签名完整性的前提下,提供了额外的功能。
介绍
意图:动态地给一个对象添加一些额外的职责。就增加功能来说,装饰器模式相比生成子类更为灵活。
主要解决:一般的,我们为了扩展一个类经常使用继承方式实现,由于继承为类引入静态特征,并且随着扩展功能的增多,子类会很膨胀。
何时使用:在不想增加很多子类的情况下扩展类。
如何解决:将具体功能职责划分,同时继承装饰者模式。
关键代码: 1、Component 类充当抽象角色,不应该具体实现。 2、修饰类引用和继承 Component 类,具体扩展类重写父类方法。
应用实例: 1、孙悟空有 72 变,当他变成"庙宇"后,他的根本还是一只猴子,但是他又有了庙宇的功能。 2、不论一幅画有没有画框都可以挂在墙上,但是通常都是有画框的,并且实际上是画框被挂在墙上。在挂在墙上之前,画可以被蒙上玻璃,装到框子里;这时画、玻璃和画框形成了一个物体。
优点:装饰类和被装饰类可以独立发展,不会相互耦合,装饰模式是继承的一个替代模式,装饰模式可以动态扩展一个实现类的功能。
缺点:多层装饰比较复杂。
使用场景: 1、扩展一个类的功能。 2、动态增加功能,动态撤销。
注意事项:可代替继承。
应用场景
装饰者模式在我们生活中应用也比较多如给煎饼加鸡蛋;给蛋糕加上一些水果;给房子装修等,为对象扩展一些额外的职责。装饰者在代码程序中适用于以下场景:
1、用于扩展一个类的功能或给一个类添加附加职责。
2、动态的给一个对象添加功能,这些功能可以再动态的撤销。
来看一个这样的场景,上班族白领其实大多有睡懒觉的习惯,每天早上上班都是踩点,于是很多小伙伴为了多赖一会儿床都不吃早餐。那么,也有些小伙伴可能在上班路上碰到卖煎饼的路边摊,都会顺带一个到公司茶水间吃早餐。卖煎饼的大姐可以给你的煎饼加鸡蛋,也可以加香肠(如下图,PS:我买煎饼一般都要求不加生菜)。
下面我们用代码还原一下码农的生活。首先创建一个煎饼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个鸡蛋";
}
@Override
//加一个鸡蛋加1块钱
public int getPrice() {
return super.getPrice() + 1;
}
}
再创建一个既加鸡蛋又加香肠的BattercakeWithEggAndSausage类:
public class BattercakeWithEggAndSausage extends BattercakeWithEgg{
@Override
protected String getMsg() {
return super.getMsg() + "+1根香肠";
}
@Override
//加一个香肠加2块钱
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);
battercake = new SausageDecorator(battercake);
battercake = new SausageDecorator(battercake);
battercake = new SausageDecorator(battercake);
battercake = new SausageDecorator(battercake);
//跟静态代理最大区别就是职责不同
//静态代理不一定要满足is-a的关系
//静态代理会做功能增强,同一个职责变得不一样
//装饰器更多考虑是扩展
System.out.println(battercake.getMsg() + ",总价:" + battercake.getPrice());
}
}
运行结果:
煎饼+1个鸡蛋+1根香肠+1根香肠+1根香肠+1根香肠+1根香肠,总价:16
来看一下类图:
为了加深印象,我们再来看一个应用场景。是否还有小伙伴记得我们上次讲个的适配器模式,为了实现新功能与老功能兼容,创建一个新的类继承已有的类,实现功能扩展,遵循开闭原则。今天我们再用装饰者模式再来升级一次代码,同时也做一个更好的对比。先看原来的代码,Member类:
public class Member {
private String username;
private String password;
private String mid;
private String info;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
public String getMid() {
return mid;
}
public void setMid(String mid) {
this.mid = mid;
}
public String getInfo() {
return info;
}
public void setInfo(String info) {
this.info = info;
}
}
ResultMsg类:
public class ResultMsg {
private int code;
private String msg;
private Object data;
public ResultMsg(int code, String msg, Object data) {
this.code = code;
this.msg = msg;
this.data = data;
}
public int getCode() {
return code;
}
public void setCode(int code) {
this.code = code;
}
public String getMsg() {
return msg;
}
public void setMsg(String msg) {
this.msg = msg;
}
public Object getData() {
return data;
}
public void setData(Object data) {
this.data = data;
}
}
ISigninService接口:
public interface ISigninService {
ResultMsg regist(String username, String password);
/**
* 登录的方法
* @param username
* @param password
* @return
*/
ResultMsg login(String username, String password);
}
SigninService实现类:
public class SigninService implements ISigninService {
public ResultMsg regist(String username,String password){
return new ResultMsg(200,"注册成功",new Member());
}
/**
* 登录的方法
* @param username
* @param password
* @return
*/
public ResultMsg login(String username,String password){
return null;
}
}
来看升级以后的代码,创建一个新的接口继承原来的接口:
public interface ISiginForThirdService extends ISigninService {
/**
* QQ登录
* @param id
* @return
*/
ResultMsg loginForQQ(String id);
/**
* 微信登录
* @param id
* @return
*/
ResultMsg loginForWechat(String id);
/**
* 记住登录状态后自动登录
* @param token
* @return
*/
ResultMsg loginForToken(String token);
/**
* 手机号登录
* @param telphone
* @param code
* @return
*/
ResultMsg loginForTelphone(String telphone, String code);
/**
* 注册后自动登录
* @param username
* @param passport
* @return
*/
ResultMsg loginForRegist(String username, String passport);
}
创建新的逻辑处理类SigninForThirdService,实现新创建的接口:
public class SiginForThirdService implements ISiginForThirdService {
private ISigninService signinService;
public SiginForThirdService(ISigninService signinService) {
this.signinService = signinService;
}
public ResultMsg regist(String username, String password) {
return signinService.regist(username,password);
}
public ResultMsg login(String username, String password) {
return signinService.login(username,password);
}
public ResultMsg loginForQQ(String id) {
return null;
}
public ResultMsg loginForWechat(String id) {
return null;
}
public ResultMsg loginForToken(String token) {
return null;
}
public ResultMsg loginForTelphone(String telphone, String code) {
return null;
}
public ResultMsg loginForRegist(String username, String passport) {
return null;
}
}
客户端测试代码:
public class DecoratorTest {
public static void main(String[] args) {
//满足一个is-a
ISiginForThirdService siginForThirdService = new SiginForThirdService(new SigninService());
siginForThirdService.loginForQQ("sdfasfdasfsf");
}
}
装饰者模式最本质的特征是将原有类的附加功能抽离出来,简化原有类的逻辑。通过这样两个案例,我们可以总结出来,其实抽象的装饰者是可有可无的,具体可以根据业务模型来选择。
装饰者模式和适配器模式对比
装饰者和适配器模式都是包装模式(WrapperPattern),装饰者也是一种特殊的代理模式。
装饰者模式 | 适配器模式 | |
---|---|---|
形式 | 是一种非常特别的适配器模式 没有层级关系 | 装饰器模式有层级关系 |
定义 | 装饰者和被装饰者都实现同一个接 口,主要目的是为了扩展之后依旧保 留OOP关系 |
适配器和被适配者没有必然的联系,通 常是采用继承或代理的形式进行包装 |
关系 | 满足is-a的关系 | 满足has-a的关系 |
功能 | 注重覆盖、扩展 | 注重兼容、转换 |
设计 | 前置考虑 | 后置考虑 |
装饰者模式在源码中的应用
装饰器模式在源码中也应用得非常多,在 JDK 中体现最明显的类就是 IO 相关的类,如BufferedReader、InputStream、OutputStream,看一下常用的InputStream的类结构图:
在Spring中的TransactionAwareCacheDecorator类我们也可以来尝试理解一下,这个类主要是用来处理事务缓存的,来看一下代码:
public class TransactionAwareCacheDecorator implements Cache {
private final Cache targetCache;
/**
* Create a new TransactionAwareCache for the given target Cache.
* @param targetCache the target Cache to decorate
*/
public TransactionAwareCacheDecorator(Cache targetCache) {
Assert.notNull(targetCache, "Target Cache must not be null");
this.targetCache = targetCache;
}
/**
* Return the target Cache that this Cache should delegate to.
*/
public Cache getTargetCache() {
return this.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事务相关的缓存,都是采用装饰者模式。
一些信息
路漫漫其修远兮,吾将上下而求索
码云:https://gitee.com/javacoo
QQ群:164863067
作者/微信:javacoo
邮箱:[email protected]