30讲装饰器模式：如何优化电商系统中复杂的商品价格策略
你好，我是刘超。
开始今天的学习之前，我想先请你思考⼀个问题。假设现在有这样⼀个需求，让你设计⼀个装修功能，⽤户可以动态选择不同的装修功能来装饰⾃⼰的房⼦。例如，⽔电装修、天花板以及粉刷墙等属于基本功能，⽽设计窗帘装饰窗户、设计吊顶装饰房顶等未必是所有⽤户都需要的，这些功能则需要实现动态添加。还有就是⼀旦有新的装修功能，我们也可以实现动态添加。如果要你来负责，你会怎么设计呢？
此时你可能会想了，通常给⼀个对象添加功能，要么直接修改代码，在对象中添加相应的功能，要么派⽣对应的⼦类来扩展。然⽽，前者每次都需要修改对象的代码，这显然不是理想的⾯向对象设计，即便后者是通过派⽣对应的⼦类来扩展，也很难满
⾜复杂的随意组合功能需求。
⾯对这种情况，使⽤装饰器模式应该再合适不过了。它的优势我想你多少知道⼀点，我在这⾥总结⼀下。
装饰器模式能够实现为对象动态添加装修功能，它是从⼀个对象的外部来给对象添加功能，所以有⾮常灵活的扩展性，我们可以在对原来的代码毫⽆修改的前提下，为对象添加新功能。除此之外，装饰器模式还能够实现对象的动态组合，借此我们可以很灵活地给动态组合的对象，匹配所需要的功能。
下⾯我们就通过实践，具体看看该模式的优势。
什么是装饰器模式？
在这之前，我先简单介绍下什么是装饰器模式。装饰器模式包括了以下⼏个⻆⾊：接⼝、具体对象、装饰类、具体装饰类。
接⼝定义了具体对象的⼀些实现⽅法；具体对象定义了⼀些初始化操作，⽐如开头设计装修功能的案例中，⽔电装修、天花板以及粉刷墙等都是初始化操作；装饰类则是⼀个抽象类，主要⽤来初始化具体对象的⼀个类；其它的具体装饰类都继承了该抽象类。
下⾯我们就通过装饰器模式来实现下装修功能，代码如下：
|
/
- 定义⼀个基本装修接⼝
- @author admin
/
public interface IDecorator {
/
装修⽅法
/
void decorate();
} |
| —- |
|
/
- 装修基本类
- @author admin
/
public class Decorator implements IDecorator{
/
基本实现⽅法
/
public void decorate() {
System.out.println(“⽔电装修、天花板以及粉刷墙。。。”);
}
} |
| —- |
|
/
- 基本装饰类
- @author admin
/
public abstract class BaseDecorator implements IDecorator{
private IDecorator decorator;
public BaseDecorator(IDecorator decorator) { this.decorator = decorator;
}
/
调⽤装饰⽅法
/
public void decorate() { if(decorator != null) {
decorator.decorate();
}
}
} |
| —- |
|
/
- 窗帘装饰类
- @author admin
/
public class CurtainDecorator extends BaseDecorator{
public CurtainDecorator(IDecorator decorator) { super(decorator);
}
/
窗帘具体装饰⽅法
/
@Override
public void decorate() {
System.out.println(“窗帘装饰。。。”); super.decorate();
}
} |
| —- |
public static void main( String[] args ) { IDecorator decorator = new Decorator(); IDecorator curtainDecorator = new CurtainDecorator(decorator); curtainDecorator.decorate(); } |
|---|
运⾏结果：
窗帘装饰。。。 ⽔电装修、天花板以及粉刷墙。。。 |
|---|
通过这个案例，我们可以了解到：如果我们想要在基础类上添加新的装修功能，只需要基于抽象类BaseDecorator去实现继承类，通过构造函数调⽤⽗类，以及重写装修⽅法实现装修窗帘的功能即可。在main函数中，我们通过实例化装饰类，调⽤装 修⽅法，即可在基础装修的前提下，获得窗帘装修功能。
基于装饰器模式实现的装修功能的代码结构简洁易读，业务逻辑也⾮常清晰，并且如果我们需要扩展新的装修功能，只需要新增⼀个继承了抽象装饰类的⼦类即可。
在这个案例中，我们仅实现了业务扩展功能，接下来，我将通过装饰器模式优化电商系统中的商品价格策略，实现不同促销活
动的灵活组合。
优化电商系统中的商品价格策略
相信你⼀定不陌⽣，购买商品时经常会⽤到的限时折扣、红包、抵扣券以及特殊抵扣⾦等，种类很多，如果换到开发视⻆，实现起来就更复杂了。
例如，每逢双⼗⼀，为了加⼤商城的优惠⼒度，开发往往要设计红包+限时折扣或红包+抵扣券等组合来实现多重优惠。⽽在平时，由于某些特殊原因，商家还会赠送特殊抵扣券给购买⽤户，⽽特殊抵扣券+各种优惠⼜是另⼀种组合⽅式。
要实现以上这类组合优惠的功能，最快、最普遍的实现⽅式就是通过⼤量if-else的⽅式来实现。但这种⽅式包含了⼤量的逻辑判断，致使其他开发⼈员很难读懂业务， 并且⼀旦有新的优惠策略或者价格组合策略出现，就需要修改代码逻辑。
这时，刚刚介绍的装饰器模式就很适合⽤在这⾥，其相互独⽴、⾃由组合以及⽅便动态扩展功能的特性，可以很好地解决if-
else⽅式的弊端。下⾯我们就⽤装饰器模式动⼿实现⼀套商品价格策略的优化⽅案。
⾸先，我们先建⽴订单和商品的属性类，在本次案例中，为了保证简洁性，我只建⽴了⼏个关键字段。以下⼏个重要属性关系为，主订单包含若⼲详细订单，详细订单中记录了商品信息，商品信息中包含了促销类型信息，⼀个商品可以包含多个促销类型（本案例只讨论单个促销和组合促销）：
|
/*
- 主订单
- @author admin
*/
public class Order {
private int id; // 订 单 ID private String orderNo; //订单号
private BigDecimal totalPayMoney; //总⽀付⾦额private List
} |
| —- |
|
/*
- 详细订单
- @author admin
*/
public class OrderDetail { private int id; //详细订单ID private int orderId;//主订单ID
private Merchandise merchandise; //商品详情private BigDecimal payMoney; //⽀付单价
} |
| —- |
|
/*
- 商品
- @author admin
*/
public class Merchandise {
private String sku;// 商 品 SKU private String name; //商品名称private BigDecimal price; //商品单价
private Map
} |
| —- |
|
/*
- 促销类型
- @author admin
*/
public class SupportPromotions implements Cloneable{
private int id;//该商品促销的ID
private PromotionType promotionType;//促销类型 1\优惠券 2\红包private int priority; //优先级
private UserCoupon userCoupon; //⽤户领取该商品的优惠券private UserRedPacket userRedPacket; //⽤户领取该商品的红包
//重写clone⽅法
public SupportPromotions clone(){ SupportPromotions supportPromotions = null;
try{
supportPromotions = (SupportPromotions)super.clone();
}catch(CloneNotSupportedException e){ e.printStackTrace();
}
return supportPromotions;
}
} |
| —- |
|
/*
- 优惠券
- @author admin
*/
public class UserCoupon {
private int id; //优惠券ID
private int userId; //领取优惠券⽤户ID private String sku; // 商 品 SKU private BigDecimal coupon; //优惠⾦额
} |
| —- |
|
/*
- 红包
- @author admin
*/
public class UserRedPacket {
private int id; // 红 包 ID private int userId; //领取⽤户ID private String sku; //商品SKU
private BigDecimal redPacket; //领取红包⾦额
} |
| —- |
接下来，我们再建⽴⼀个计算⽀付⾦额的接⼝类以及基本类：
|
/*
- 计算⽀付⾦额接⼝类
- @author admin
*/
public interface IBaseCount {
BigDecimal countPayMoney(OrderDetail orderDetail);
} |
| —- |
|
/*
- ⽀付基本类
- @author admin
*/
public class BaseCount implements IBaseCount{
public BigDecimal countPayMoney(OrderDetail orderDetail) { orderDetail.setPayMoney(orderDetail.getMerchandise().getPrice());
System.out.println(“商品原单价⾦额为：” + orderDetail.getPayMoney());
return orderDetail.getPayMoney();
}
} |
| —- |
然后，我们再建⽴⼀个计算⽀付⾦额的抽象类，由抽象类调⽤基本类：
|
/*
- 计算⽀付⾦额的抽象类
- @author admin
*/
public abstract class BaseCountDecorator implements IBaseCount{
private IBaseCount count;
public BaseCountDecorator(IBaseCount count) { this.count = count;
}
public BigDecimal countPayMoney(OrderDetail orderDetail) { BigDecimal payTotalMoney = new BigDecimal(0); if(count!=null) {
payTotalMoney = count.countPayMoney(orderDetail);
}
return payTotalMoney;
}
} |
| —- |
然后，我们再通过继承抽象类来实现我们所需要的修饰类（优惠券计算类、红包计算类）：
/**
- 计算使⽤优惠券后的⾦额
- @author admin
/
public class CouponDecorator extends BaseCountDecorator{
public CouponDecorator(IBaseCount count) { super(count);
}
public BigDecimal countPayMoney(OrderDetail orderDetail) { BigDecimal payTotalMoney = new BigDecimal(0); payTotalMoney = super.countPayMoney(orderDetail); payTotalMoney = countCouponPayMoney(orderDetail);
return payTotalMoney;
}
private BigDecimal countCouponPayMoney(OrderDetail orderDetail) {
BigDecimal coupon = orderDetail.getMerchandise().getSupportPromotions().get(PromotionType.COUPON).getUserCo
System.out.println(“优惠券⾦额：” + coupon);
orderDetail.setPayMoney(orderDetail.getPayMoney().subtract(coupon)); return orderDetail.getPayMoney();
}
}
|
/*
- 计算使⽤红包后的⾦额
- @author admin
*/
public class RedPacketDecorator extends BaseCountDecorator{
public RedPacketDecorator(IBaseCount count) { super(count);
}
public BigDecimal countPayMoney(OrderDetail orderDetail) { BigDecimal payTotalMoney = new BigDecimal(0); payTotalMoney = super.countPayMoney(orderDetail); payTotalMoney = countCouponPayMoney(orderDetail);
return payTotalMoney;
}
private BigDecimal countCouponPayMoney(OrderDetail orderDetail) {
BigDecimal redPacket = orderDetail.getMerchandise().getSupportPromotions().get(PromotionType.REDPACKED).getU
System.out.println(“红包优惠⾦额：” + redPacket);
orderDetail.setPayMoney(orderDetail.getPayMoney().subtract(redPacket)); return orderDetail.getPayMoney();
}
} |
| —- |
| 
|
| |
最后，我们通过⼀个⼯⼚类来组合商品的促销类型：
/**
- 计算促销后的⽀付价格
- @author admin
/
public class PromotionFactory {
public static BigDecimal getPayMoney(OrderDetail orderDetail) {
//获取给商品设定的促销类型
Map
//初始化计算类
IBaseCount baseCount = new BaseCount(); if(supportPromotionslist!=null && supportPromotionslist.size()>0) {
for(PromotionType promotionType: supportPromotionslist.keySet()) {//遍历设置的促销类型，通过装饰器组合促销类型
baseCount = protmotion(supportPromotionslist.get(promotionType), baseCount);
}
}
return baseCount.countPayMoney(orderDetail);
}
/**
- 组合促销类型
- @param supportPromotions
- @param baseCount
- @return
*/
private static IBaseCount protmotion(SupportPromotions supportPromotions, IBaseCount baseCount) { if(supportPromotions.getPromotionType()==PromotionType.COUPON) {
baseCount = new CouponDecorator(baseCount);
}else if(supportPromotions.getPromotionType()==PromotionType.REDPACKED) { baseCount = new RedPacketDecorator(baseCount);
}
return baseCount;
}
}
public static void main( String[] args ) throws InterruptedException, IOException { Order order = new Order(); init(order); for(OrderDetail orderDetail: order.getList()) { BigDecimal payMoney = PromotionFactory.getPayMoney(orderDetail); orderDetail.setPayMoney(payMoney); System.out.println(“最终⽀付⾦额：” + orderDetail.getPayMoney()); } } |
|---|
运⾏结果：
商品原单价⾦额为：20 优惠券⾦额：3 红包优惠⾦额：10 最终⽀付⾦额：7 |
|---|
以上源码可以通过 Github 下载运⾏。通过以上案例可知：使⽤装饰器模式设计的价格优惠策略，实现各个促销类型的计算功能都是相互独⽴的类，并且可以通过⼯⼚类⾃由组合各种促销类型。
总结
这讲介绍的装饰器模式主要⽤来优化业务的复杂度，它不仅简化了我们的业务代码，还优化了业务代码的结构设计，使得整个业务逻辑清晰、易读易懂。
通常，装饰器模式⽤于扩展⼀个类的功能，且⽀持动态添加和删除类的功能。在装饰器模式中，装饰类和被装饰类都只关⼼⾃身的业务，不相互⼲扰，真正实现了解耦。
思考题
责任链模式、策略模式与装饰器模式有很多相似之处。平时，这些设计模式除了在业务中被⽤到以外，在架构设计中也经常被
⽤到，你是否在源码中⻅过这⼏种设计模式的使⽤场景呢？欢迎你与⼤家分享。
精选留⾔ <br />密码123456<br />责任链。最常⻅到的就是接收http请求了。帮我们转码，转化成实体类，等等。策略模式。最常简单和⽤到的就是集合排序，<br />⾃定义排序规则。装饰器，最常⻅到的就是各种流，⽐如字符流，字节流等<br />2019-08-01 08:17<br />作者回复
2019-08-02 10:27
nightmare
netty中的pipeline，tomcat中的filter，属于责任链， springmvc中对参数解析的就是 策略模式，每⼀个参数类型⼀个实现类，
⽤for循环解析参数 java. io就是经典的装饰器模式
2019-08-01 01:03
作者回复
有读源码习惯
2019-08-02 10:27
CCC
有⼏个今年秋招的！举个⼿！⽼师的课程真的收获很多！
2019-08-01 00:18
峰
感觉⽼师在红包这个例⼦⾥⾯，其实最重要的解耦是装饰器实现的各种基本的优惠打折⼿段与⼯⼚的各种优惠规则⽐如红包抵
⽤券可叠加等等。
2019-08-02 08:16
作者回复
对的，主要⽤来优化业务的复杂度。
2019-08-02 10:04
QQ怪
⽼师这个案例来的太及时了，正想重构公司订单优惠劵红包扣除这⽅⾯的代码，真的是及时⾬啊？厉害厉害
2019-08-01 21:19
冯传博
希望能有个类图，这样就能⼀⽬了然的看清楚各个类之间的关系了
2019-08-01 08:59
作者回复
好的，后续补上
2019-08-02 10:25
-W.LI-
public BigDecimal countPayMoney(OrderDetail orderDetail) { BigDecimal payTotalMoney = new BigDecimal(0); payTotalMoney = super.countPayMoney(orderDetail); payTotalMoney = countCouponPayMoney(orderDetail); return payTotalMoney;
}
⽼师好!这⾥为啥要调⽤⽗类的countPayMoney()⽅法啊?
责任链模式:感觉责任连模式⽐较固定不怎么会变⼀层往⼀层调⽤，解耦，某⼀层变了不影响别的层。
策略模式:策略模式，虽然也是封装了很多不同的策略，但是使⽤时⼀般⼀次只选⼀个实现类使⽤，不会有嵌套。装饰者模式:责任链有的优点他都有，装饰者还能动态组合。
谢谢⽼师，希望给出详细答案谢谢
2019-08-01 08:33
作者回复
由于我们这⾥考虑到灵活的组合模式，所以需要调⽤⽗类的countPayMoney()⽅法。
2019-08-02 10:26
Gred
⽼师您这段优化的装饰器模式代码⾥⾯，就⽤到装饰器、责任链以及⼯⼚模式。不愧是⽼师，厉害厉害。
2019-08-14 00:04
Gred
⽼师，您在SupportPromotions重写 clone ⽅法，只对类进⾏拷⻉，但是成员变量只是浅拷⻉，如果要实际应⽤业务场景，是不是应该改⽤深拷⻉，避免其他订单的优化券等信息影响到了。
2019-08-13 23:56
知⾏合⼀
BigDecimal payTotalMoney = new BigDecimal(0); payTotalMoney = super.countPayMoney(orderDetail); payTotalMoney = countCouponPayMoney(orderDetail);
payTotalMoney不就被覆盖了吗？
2019-08-08 18:55
作者回复
第⼀个是计算原价，第⼆个是计算使⽤优惠券后的价格，我们可以将第⼀个去掉，这⾥只是冗余了⼀个payTotalMoney。
2019-08-09 09:15
Liam
请问⽼师，装饰器和代理有什么区别呢，代理也可以实现被代理的接⼝，并注⼊被代理对象实现功能扩展，最后可以委托被代理对象完成基础功能
2019-08-06 08:22
若有收获，就点个赞吧
0 人点赞
