研磨设计模式 之 装饰模式（Decorator）1

22.1  场景问题

22.1.1  复杂的奖金计算

       考虑这样一个实际应用：就是如何实现灵活的奖金计算。

奖金计算是相对复杂的功能，尤为是对于业务部门的奖金计算方式，是很是复杂的，除了业务功能复杂外，另一个麻烦之处是计算方式还常常须要变更，由于业务部门常常经过调整奖金的计算方式来激励士气。

       先从业务上看看现有的奖金计算方式的复杂性：

• 首先是奖金分类：对于我的，大体有我的当月业务奖金、我的累计奖金、我的业务增加奖金、及时回款奖金、限时成交加码奖金等等；

• 对于业务主管或者是业务经理，除了我的奖金外，还有：团队累计奖金、团队业务增加奖金、团队盈利奖金等等。

• 其次是计算奖金的金额，又有这么几个基数：销售额、销售毛利、实际回款、业务成本、奖金基数等等；

• 另一个就是计算的公式，针对不一样的人、不一样的奖金类别、不一样的计算奖金的金额，计算的公式是不一样的，就算是同一个公式，里面计算的比例参数也有多是不一样的。

22.1.2  简化后的奖金计算体系

看了上面奖金计算的问题，所幸咱们只是来学习设计模式，并非真的要去实现整个奖金计算体系的业务，所以也没有必要把全部的计算业务都罗列在这里，为了后面演示的须要，简化一下，演示用的奖金计算体系以下：

• 每一个人当月业务奖金 = 当月销售额 X  3%

• 每一个人累计奖金 = 总的回款额 X  0.1%

• 团队奖金 = 团队总销售额 X 1%

22.1.3  不用模式的解决方案

一我的的奖金分红不少个部分，要实现奖金计算，主要就是要按照各个奖金计算的规则，把这我的能够获取的每部分奖金计算出来，而后计算一个总和，这就是这我的能够获得的奖金。

（1）为了演示，先准备点测试数据，在内存中模拟数据库，示例代码以下：

/**  * 在内存中模拟数据库，准备点测试数据，好计算奖金  */ 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);     } }

（2）按照奖金计算的规则，实现奖金计算，示例代码以下：

/**  * 计算奖金的对象  */ 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;     } }

（3）写个客户端来测试一下，看看是否能正确地计算奖金，示例代码以下：

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);     } }

测试运行的结果以下：

张三当月业务奖金300.0 张三累计奖金1000.0 ==========张三应得奖金：1300.0 李四当月业务奖金600.0 李四累计奖金1000.0 ==========李四应得奖金：1600.0 王五当月业务奖金900.0 王五累计奖金1000.0 王五当月团队业务奖金600.0 ==========王经理应得奖金：2500.0

22.1.4  有何问题

看了上面的实现，挺简单的嘛，就是计算方式麻烦点，每一个规则都要实现。真的很简单吗？仔细想一想，有没有什么问题？

对于奖金计算，光是计算方式复杂，也就罢了，不过是实现起来会困难点，相对而言仍是比较好解决的，不过是用程序把已有的算法表达出来。

最痛苦的是，这些奖金的计算方式，常常发生变更，几乎是每一个季度都会有小调整，每一年都有大调整，这就要求软件的实现要足够灵活，要可以很快进行相应调整和修改，不然就不能知足实际业务的须要。

       举个简单的例子来讲，如今根据业务须要，须要增长一个“环比增加奖金”，就是本月的销售额比上个月有增长，并且要达到必定的比例，固然增加比例越高，奖金比例越大。那么软件就必需要从新实现这么个功能，并正确的添加到系统中去。过了两个月，业务奖励的策略发生了变化，再也不须要这个奖金了，或者是另外换了一个新的奖金方式了，那么软件就须要把这个功能从软件中去掉，而后再实现新的功能。

       那么上面的要求该如何实现呢？

       很明显，一种方案是经过继承来扩展功能；另一种方案就是到计算奖金的对象里面，添加或者删除新的功能，并在计算奖金的时候，调用新的功能或是不调用某些去掉的功能，这种方案会严重违反开-闭原则。

       还有一个问题，就是在运行期间，不一样人员参与的奖金计算方式也是不一样的，举例来讲：若是是业务经理，除了参与我的计算部分外，还要参加团队奖金的计算，这就意味着须要在运行期间动态来组合须要计算的部分，也就是会有一堆的if-else。

       总结一下，奖金计算面临以下问题：

• （1）计算逻辑复杂

• （2）要有足够灵活性，能够方便的增长或者减小功能

• （3）要能动态的组合计算方式，不一样的人参与的计算不一样

上面描述的奖金计算的问题，绝对没有任何夸大成分，相反已经简化很多了，还有更多麻烦没有写上来，毕竟咱们的重点在设计模式，而不是业务。

把上面的问题抽象一下，设如有一个计算奖金的对象，如今须要可以灵活的给它增长和减小功能，还须要可以动态的组合功能，每一个功能就至关于在计算奖金的某个部分。

       如今的问题就是：如何才可以透明的给一个对象增长功能，并实现功能的动态组合呢？

 

原创内容，转载请注明出处【http://sishuok.com/forum/blogPost/list/0/5764.html】