本文节选自《设计模式就该这样学》
1 使用装饰器模式解决煎饼加码问题
来看这样一个场景，上班族大多有睡懒觉的习惯，每天早上上班都时间很紧张，于是很多人为了多睡一会儿，就用更方便的方式解决早餐问题，有些人早餐可能会吃煎饼。煎饼中可以加鸡蛋，也可以加香肠，但是不管怎么加码，都还是一个煎饼。再比如，给蛋糕加上一些水果，给房子装修，都是装饰器模式。
下面用代码来模拟给煎饼加码的业务场景，先来看不用装饰器模式的情况。首先创建一个煎饼 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个鸡蛋加1元钱 public int getPrice() { return super.getPrice() + 1; }}
复制代码
再创建一个既加鸡蛋又加香肠的 BattercakeWithEggAndSausage 类。
public class BattercakeWithEggAndSausage extends BattercakeWithEgg{ @Override protected String getMsg() { return super.getMsg() + "+1根香肠"; }
@Override //加1根香肠加2元钱 public int getPrice() { return super.getPrice() + 2; }}
复制代码
最后编写客户端测试代码。
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());
}
复制代码
运行结果如下图所示。
运行结果没有问题。但是，如果用户需要一个加 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(); //煎饼有点小，想再加1个鸡蛋 battercake = new EggDecorator(battercake); //再加1个鸡蛋 battercake = new EggDecorator(battercake); //很饿，再加1根香肠 battercake = new SausageDecorator(battercake);
//与静态代理的最大区别就是职责不同 //静态代理不一定要满足is-a的关系 //静态代理会做功能增强，同一个职责变得不一样
//装饰器更多考虑的是扩展 System.out.println(battercake.getMsg() + ",总价：" + battercake.getPrice()); }}
复制代码
运行结果如下图所示。
最后来看类图，如下图所示。
2 使用装饰器模式扩展日志格式输出
为了加深印象，我们再来看一个应用场景。需求大致是这样的，系统采用的是 SLS 服务监控项目日志，以 JSON 格式解析，因此需要将项目中的日志封装成 JSON 格式再打印。现有的日志体系采用 Log4j + Slf4j 框架搭建而成。客户端调用如下。
private static final Logger logger = LoggerFactory.getLogger(Component.class); logger.error(string);
复制代码
这样打印出来的是毫无规则的一行行字符串。当考虑将其转换成 JSON 格式时，笔者采用装饰器模式。目前有的是统一接口 Logger 和其具体实现类，笔者要加的就是一个装饰类和真正封装成 JSON 格式的装饰产品类。创建装饰器类 DecoratorLogger。
public class DecoratorLogger implements Logger {
public Logger logger;
public DecoratorLogger(Logger logger) {
this.logger = logger; }
public void error(String str) {}
public void error(String s, Object o) {
} //省略其他默认实现}
复制代码
创建具体组件 JsonLogger 类。
public class JsonLogger extends DecoratorLogger { public JsonLogger(Logger logger) { super(logger); } @Override public void info(String msg) {
JSONObject result = composeBasicJsonResult(); result.put("MESSAGE", msg); logger.info(result.toString()); } @Override public void error(String msg) { JSONObject result = composeBasicJsonResult(); result.put("MESSAGE", msg); logger.error(result.toString()); } public void error(Exception e) {
JSONObject result = composeBasicJsonResult(); result.put("EXCEPTION", e.getClass().getName()); String exceptionStackTrace = Arrays.toString(e.getStackTrace()); result.put("STACKTRACE", exceptionStackTrace); logger.error(result.toString()); } private JSONObject composeBasicJsonResult() { //拼装了一些运行时的信息 return new JSONObject(); }}
复制代码
可以看到，在 JsonLogger 中，对于 Logger 的各种接口，我们都用 JsonObject 对象进行一层封装。在打印的时候，最终还是调用原生接口 logger.error(string)，只是这个 String 参数已经被装饰过了。如果有额外的需求，则可以再写一个函数去实现。比如 error(Exception e)，只传入一个异常对象，这样在调用时就非常方便。另外，为了在新老交替的过程中尽量不改变太多代码和使用方式，笔者又在 JsonLogger 中加入了一个内部的工厂类 JsonLoggerFactory（这个类转移到 DecoratorLogger 中可能更好一些）。它包含一个静态方法，用于提供对应的 JsonLogger 实例。最终在新的日志体系中，使用方式如下。
private static final Logger logger = JsonLoggerFactory.getLogger(Client.class);
public static void main(String[] args) {
logger.error("错误信息"); }
复制代码
对于客户端而言，唯一与原先不同的地方就是将 LoggerFactory 改为 JsonLoggerFactory 即可，这样的实现，也会更快更方便地被其他开发者接受和习惯。最后看如下图所示的类图。
装饰器模式最本质的特征是将原有类的附加功能抽离出来，简化原有类的逻辑。通过这样两个案例，我们可以总结出来，其实抽象的装饰器是可有可无的，具体可以根据业务模型来选择。
【推荐】Tom弹架构：收藏本文，相当于收藏一本“设计模式”的书
本文为“Tom 弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！
如果本文对您有帮助，欢迎关注和点赞；如果您有任何建议也可留言评论或私信，您的支持是我坚持创作的动力。关注微信公众号『 Tom 弹架构 』可获取更多技术干货！
评论