一、动机
在软件系统中，由于需求的变化，一个对象的功能实现经常面临着扩展变化，但是功能接口方法比较稳定。如何使“对象功能实现的扩展变化”能够根据需要来动态地实现？
我们来看下怎样使用装饰器模式来应对功能的扩展变化。
二、需求变化过程
1、软件需求
考虑一个实际应用：实现灵活的奖金计算。
奖金计算的特点就是业务功能复杂，还有一个变化点就是计算方式经常需要变动，因为业务部门要通过调整奖金的计算方式来激励士气。奖金计算体系包括三种：每个人当月业务奖金、每个人累计奖金、团队奖金。
2、不用模式的解决方案
普通作法：一个人的奖金分成很多个部分，要实现奖金计算，主要就是要按照各个奖金计算的规则，把这个人可以获取的每部分奖金计算出来，然后计算一个总和，这就是这个人可以得到的奖金。
测试数据：
import java.util.*; /** * 在内存中模拟数据库，准备点测试数据，好计算奖金 */ public class TempDB { private TempDB(){} /** * 记录每个人的月度销售额，只用了人员，月份没有用 */ public static Map<String,Double> mapMonthSaleMoney = new HashMap<String,Double>(); static{ //填充测试数据 mapMonthSaleMoney.put("张三",10000.0); mapMonthSaleMoney.put("李四",20000.0); mapMonthSaleMoney.put("王五",30000.0); } }
奖金计算类：
import java.util.Date; /** * 计算奖金的对象 */ public class Prize { /** * 计算某人在某段时间内的奖金，有些参数在演示中并不会使用， * 但是在实际业务实现上是会用的，为了表示这是个具体的业务方法， * 因此这些参数被保留了 * @param user 被计算奖金的人员 * @param begin 计算奖金的开始时间 * @param end 计算奖金的结束时间 * @return 某人在某段时间内的奖金 */ public double calcPrize(String user,Date begin,Date end){ double prize = 0.0; //计算当月业务奖金，所有人都会计算 prize = this.monthPrize(user, begin, end); //计算累计奖金 prize += this.sumPrize(user, begin, end); //需要判断该人员是普通人员还是业务经理，团队奖金只有业务经理才有 if(this.isManager(user)){ prize += this.groupPrize(user, begin, end); } return prize; } /** * 计算某人的当月业务奖金，参数重复，就不再注释了 */ private double monthPrize(String user, Date begin, Date end) { //计算当月业务奖金,按照人员去获取当月的业务额，然后再乘以3% double prize = TempDB.mapMonthSaleMoney.get(user) * 0.03; System.out.println(user+"当月业务奖金"+prize); return prize; } /** * 计算某人的累计奖金，参数重复，就不再注释了 */ public double sumPrize(String user, Date begin, Date end) { //计算累计奖金,其实这里应该按照人员去获取累计的业务额，然后再乘以0.1% //简单演示一下，假定大家的累计业务额都是1000000元 double prize = 1000000 * 0.001; System.out.println(user+"累计奖金"+prize); return prize; } /** * 判断人员是普通人员还是业务经理 * @param user 被判断的人员 * @return true表示是业务经理,false表示是普通人员 */ private boolean isManager(String user){ //应该从数据库中获取人员对应的职务 //为了演示，简单点判断，只有王五是经理 if("王五".equals(user)){ return true; } return false; } /** * 计算当月团队业务奖，参数重复，就不再注释了 */ public double groupPrize(String user, Date begin, Date end) { //计算当月团队业务奖金，先计算出团队总的业务额，然后再乘以1%，假设都是一个团队的 double group = 0.0; for(double d : TempDB.mapMonthSaleMoney.values()){ group += d; } double prize = group * 0.01; System.out.println(user+"当月团队业务奖金"+prize); return prize; } }
客户端：
public class Client { public static void main(String[] args) { //先创建计算奖金的对象 Prize p = new Prize(); //日期对象都没有用上，所以传null就可以了 double zs = p.calcPrize("张三",null,null); System.out.println("==========张三应得奖金："+zs); double ls = p.calcPrize("李四",null,null); System.out.println("==========李四应得奖金："+ls); double ww = p.calcPrize("王五",null,null); System.out.println("==========王经理应得奖金："+ww); } }
3、问题
如果软件没有需求变化，不使用设计模式是没有问题的。但是在这个应用中，奖金的计算方式经常发生变动，几乎每个季度都会有小调整，每年都有大调整，这就要求软件的实现要足够灵活，要能够很快进行相应的调整和修改，否则就不能满足实际业务的需要。
比如现在根据业务需要，增加一个“环比增长奖金”，那么就需要在奖金计算类中，添加新的功能方法，在计算奖金时调用新的功能方法。过了两个月，业务奖励的策略发生了变化，不再需要这个奖金了，或者换了一个新的奖金方式，又要修改奖金计算类。违反了开闭原则。
三、使用装饰者模式解决问题
我们看下，使用装饰者模式来重写刚才的案例，应对扩展功能经常变化的问题。
首先定义奖金计算组件的接口（抽象类），里面定义了计算奖金的方法。代码如下：
/** * 计算奖金的组件接口 */ public abstract class Component { /** * 计算某人在某段时间内的奖金，有些参数在演示中并不会使用， * 但是在实际业务实现上是会用的，为了表示这是个具体的业务方法， * 因此这些参数被保留了 * @param user 被计算奖金的人员 * @param begin 计算奖金的开始时间 * @param end 计算奖金的结束时间 * @return 某人在某段时间内的奖金 */ public abstract double calcPrize(String user,Date begin,Date end); }
奖金计算接口（抽象类）的基本实现，实现了计算奖金方法的默认实现：
/** * 基本的实现计算奖金的类，也是被装饰器装饰的对象 */ public class ConcreteComponent extends Component{ public double calcPrize(String user, Date begin, Date end) { //只是一个默认的实现，默认没有奖金 return 0; } }
定义抽象的装饰器，也就是各个装饰器的父类，这个父类继承了奖金计算组件的抽象类，同时持有被装饰的组件对象：
import java.util.Date; /** * 装饰器的接口，需要跟被装饰的对象实现同样的接口 */ public abstract class Decorator extends Component{ /** * 持有被装饰的组件对象 */ protected Component c; /** * 通过构造方法传入被装饰的对象 * @param c被装饰的对象 */ public Decorator(Component c){ this.c = c; } public double calcPrize(String user, Date begin, Date end) { //转调组件对象的方法 return c.calcPrize(user, begin, end); } }
定义一系列的具体装饰者对象。
用一个具体的装饰者对象，来实现一条计算奖金的规则。对应三个装饰者对象。
实现计算当月业务奖金的装饰器：
import java.util.Date; /** * 装饰器对象，计算当月业务奖金 */ public class MonthPrizeDecorator extends Decorator{ public MonthPrizeDecorator(Component c){ super(c); } public double calcPrize(String user, Date begin, Date end) { //1：先获取前面运算出来的奖金 double money = super.calcPrize(user, begin, end); //2：然后计算当月业务奖金,按照人员和时间去获取当月的业务额，然后再乘以3% double prize = TempDB.mapMonthSaleMoney.get(user) * 0.03; System.out.println(user+"当月业务奖金"+prize); return money + prize; } }
实现计算累计奖金的装饰器：
import java.util.Date; /** * 装饰器对象，计算累计奖金 */ public class SumPrizeDecorator extends Decorator{ public SumPrizeDecorator(Component c){ super(c); } public double calcPrize(String user, Date begin, Date end) { //1：先获取前面运算出来的奖金 double money = super.calcPrize(user, begin, end); //2：然后计算累计奖金,其实这里应该按照人员去获取累计的业务额，然后再乘以0.1% //简单演示一下，假定大家的累计业务额都是1000000元 double prize = 1000000 * 0.001; System.out.println(user+"累计奖金"+prize); return money + prize; } }
实现计算当月团队业务奖金的装饰器：
import java.util.Date; /** * 装饰器对象，计算当月团队业务奖金 */ public class GroupPrizeDecorator extends Decorator{ public GroupPrizeDecorator(Component c){ super(c); } public double calcPrize(String user, Date begin, Date end) { //1：先获取前面运算出来的奖金 double money = super.calcPrize(user, begin, end); //2：然后计算当月团队业务奖金，先计算出团队总的业务额，然后再乘以1% //假设都是一个团队的 double group = 0.0; for(double d : TempDB.mapMonthSaleMoney.values()){ group += d; } double prize = group * 0.01; System.out.println(user+"当月团队业务奖金"+prize); return money + prize; } }
使用装饰器的客户端：
/** * 使用装饰模式的客户端 */ public class Client { public static void main(String[] args) { //先创建计算基本奖金的类，这也是被装饰的对象 Component c1 = new ConcreteComponent(); //然后对计算的基本奖金进行装饰，这里要组合各个装饰 //说明，各个装饰者之间最好是不要有先后顺序的限制，也就是先装饰谁和后装饰谁都应该是一样的 //先组合普通业务人员的奖金计算 Decorator d1 = new MonthPrizeDecorator(c1); Decorator d2 = new SumPrizeDecorator(d1); //注意：这里只需要使用最后组合好的对象调用业务方法即可，会依次调用回去 //日期对象都没有用上，所以传null就可以了 double zs = d2.calcPrize("张三",null,null); System.out.println("==========张三应得奖金："+zs); double ls = d2.calcPrize("李四",null,null); System.out.println("==========李四应得奖金："+ls); //如果是业务经理，还需要一个计算团队的奖金计算 Decorator d3 = new GroupPrizeDecorator(d2); double ww = d3.calcPrize("王五",null,null); System.out.println("==========王经理应得奖金："+ww); } }
四、总结
通过采用组合和继承结合的方式，装饰器模式实现了在运行时动态地扩展对象功能的能力，而且可以根据需要扩展多个功能。
装饰器模式的本质在于解决“主体类在多个方向上的扩展功能”。
当有新的需求，需要灵活的增加新的扩展能力时，只需要增加新的扩展能力类，不需要修改原有代码，遵循开闭原则。