22.1 场 景 问 题

22.1.1 复杂的奖金计算

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

奖金计算是相对复杂的功能,尤其是对于业务部门的奖金计算方式,是非常复杂的,除了业务功能复杂外,还有一个麻烦之处是计算方式还经常需要变动,因为业务部门要通过调整奖金的计算方式来激励士气。

下面从业务上看看现有的奖金计算方式的复杂性。

■ 首先是奖金分类,对于个人大致有个人当月业务奖金、个人累计奖金、个人业务增长奖金、及时回款奖金、限时成交加码奖金等;对于业务主管或者是业务经理,除了个人奖金外,还有团队累计奖金、团队业务增长奖金、团队盈利奖金等。

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

■ 另外一个就是计算的公式,针对不同的人、不同的奖金类别、不同的计算奖金的金额,计算的公式是不同的,即使是同一个公式,里面计算的比例参数也有可能是不同的。

22.1.2 简化后的奖金计算体系

看了上面奖金计算的问题,所幸我们只是来学习设计模式,并不是真的要去实现整个奖金计算体系的业务,因此也没有必要把所有的计算业务都罗列在这里。为了后面演示的需要,简化一下。演示用的奖金计算体系如下:

■ 每个人当月业务奖金=当月销售额×3%

■ 每个人累计奖金=总的回款额×0.1%

■ 团队奖金=团队总销售额×1%

22.1.3 不用模式的解决方案

一个人的奖金分成很多个部分。要实现奖金计算,主要就是要按照各个奖金计算的规则,把这个人可以获取的每部分奖金计算出来,然后计算一个总和,这就是这个人可以得到的奖金。

(1)为了演示,先准备点测试数据,在内存中模拟数据库。示例代码如下:

eae32e0924c64e698fa2631e6471bb3f

cddecebe2fec43ca97353fddbf4ad22d

(2)按照奖金计算的规则,实现奖金计算。示例代码如下:

3f06ca2717e14cf69114a6cdf3231921

39de7223224446b3834af6f717d85256

8134d259a408453faaa4e3645c90a2ab

281ab19f299e4d46a78db573b8b0dd58

(3)写个客户端来测试一下,看看是否能正确地计算奖金。示例代码如下:

a35270fbb50a451c8ffaeac5b6812693

测试运行的结果如下:

da36b89e178f48c9b556955458721ad4

22.1.4 有何问题

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

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

最痛苦的是,这些奖金的计算方式经常发生变动,几乎是每个季度都会有小调整,每年都有大调整,这就要求软件的实现要足够灵活,要能够很快进行相应的调整和修改,否则就不能满足实际业务的需要。

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

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

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

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

总结一下,奖金计算面临如下问题。

■ 计算逻辑复杂。

■ 要有足够灵活性,可以方便地增加或者减少功能。

■ 要能动态地组合计算方式,不同的人参与的计算不同。

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

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

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