研磨设计模式 之 装饰模式(Decorator)1——跟着cc学设计系列

原创 2013年12月05日 10:10:19

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)要能动态的组合计算方式,不同的人参与的计算不同

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

把上面的问题抽象一下,设若有一个计算奖金的对象,现在需要能够灵活的给它增加和减少功能,还需要能够动态的组合功能,每个功能就相当于在计算奖金的某个部分。

       现在的问题就是:如何才能够透明的给一个对象增加功能,并实现功能的动态组合呢?

 


---------------------------------------------------------------------------

私塾在线学习网原创内容  跟着cc学设计系列 之 研磨设计模式

研磨设计讨论群【252780326】

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

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

经典设计模式1:结构型模式:DECORATOR——装饰模式

1、意图 装饰模式:动态的给一个对象添加一些额外的职责(不重要的功能,只是偶然一次要执行)。就增加功能来说,Decorator模式比使用继承生成子类更为灵活。      建造过程不稳定...

设计模式——装饰模式(Decorator)

要想正确理解设计模式,首先必须明确它是为了解决什么问题而提出来的。 设计模式学习笔记 ——Shulin 转载请注明出处:http://blog.csdn.net/zhshulin 1、概念 ...

浅谈JAVA设计模式之——装饰模式(Decorator)

一、概述 动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活。 二、适用性 1.在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责。 2.处...

您的设计模式——装饰模式【Decorator Pattern 】

Ladies and gentlemen,May I get your attention,Please?,Now I’m going to talk about decorator pattern...

设计模式——装饰模式(Decorator)

要想正确理解设计模式,首先必须明确它是为了解决什么问题而提出来的。 设计模式学习笔记 ——Shulin 转载请注明出处:http://blog.csdn.net/zhshulin 1、概念 ...

基于东北F4的设计模式情景剧——第一幕 装饰模式(Decorator Pattern)

虚拟一个应用场景,通过情景化的讲述方式,随着故事情节的展开,逐步引出装饰模式的产生原因、应用场景、运作机理、优势及局限性等方面的知识。不是生搬硬套地讲述概念和条条框框,而是通过一种情景化的描述,层层深...

java设计模式——装饰模式(Decorator Pattern)

装饰模式以对客户透明的方式动态地给一个对象附加上更多的责任,换言之,客户端并不会觉得对象在装饰前和装饰后有什么不同。 装饰模式可以在不需要创造更多子类的情况下,将对象的功能加以扩展。 定义:...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)