研磨设计模式之装饰模式-1(转)
??????? 考虑这样一个实际应用：就是如何实现灵活的奖金计算。
??????? 奖金计算是相对复杂的功能，尤其是对于业务部门的奖金计算方式，是非常复杂的，除了业务功能复杂外，另外一个麻烦之处是计算方式还经常需要变动，因为业务部门经常通过调整奖金的计算方式来激励士气。
??????? 先从业务上看看现有的奖金计算方式的复杂性：
?
1.2? 简化后的奖金计算体系???????? 看了上面奖金计算的问题，所幸我们只是来学习设计模式，并不是真的要去实现整个奖金计算体系的业务，因此也没有必要把所有的计算业务都罗列在这里，为了后面演示的需要，简化一下，演示用的奖金计算体系如下：
每个人当月业务奖金 = 当月销售额 X? 3%每个人累计奖金 = 总的回款额 X? 0.1%团队奖金 = 团队总销售额 X 1%?
1.3? 不用模式的解决方案??????? 一个人的奖金分成很多个部分，要实现奖金计算，主要就是要按照各个奖金计算的规则，把这个人可以获取的每部分奖金计算出来，然后计算一个总和，这就是这个人可以得到的奖金。
（1）为了演示，先准备点测试数据，在内存中模拟数据库，示例代码如下：
?
?
?
1.4? 有何问题???????? 看了上面的实现，挺简单的嘛，就是计算方式麻烦点，每个规则都要实现。真的很简单吗？仔细想想，有没有什么问题？
??????? 对于奖金计算，光是计算方式复杂，也就罢了，不过是实现起来会困难点，相对而言还是比较好解决的，不过是用程序把已有的算法表达出来。
??????? 最痛苦的是，这些奖金的计算方式，经常发生变动，几乎是每个季度都会有小调整，每年都有大调整，这就要求软件的实现要足够灵活，要能够很快进行相应调整和修改，否则就不能满足实际业务的需要。
??????? 举个简单的例子来说，现在根据业务需要，需要增加一个“环比增长奖金”，就是本月的销售额比上个月有增加，而且要达到一定的比例，当然增长比例越高，奖金比例越大。那么软件就必须要重新实现这么个功能，并正确的添加到系统中去。过了两个月，业务奖励的策略发生了变化，不再需要这个奖金了，或者是另外换了一个新的奖金方式了，那么软件就需要把这个功能从软件中去掉，然后再实现新的功能。
??????? 那么上面的要求该如何实现呢？
??????? 很明显，一种方案是通过继承来扩展功能；另外一种方案就是到计算奖金的对象里面，添加或者删除新的功能，并在计算奖金的时候，调用新的功能或是不调用某些去掉的功能，这种方案会严重违反开-闭原则。
?还有一个问题，就是在运行期间，不同人员参与的奖金计算方式也是不同的，举例来说：如果是业务经理，除了参与个人计算部分外，还要参加团队奖金的计算，这就意味着需要在运行期间动态来组合需要计算的部分，也就是会有一堆的if-else。
??????? 总结一下，奖金计算面临如下问题：
?????? 上面描述的奖金计算的问题，绝对没有任何夸大成分，相反已经简化不少了，还有更多麻烦没有写上来，毕竟我们的重点在设计模式，而不是业务。
?????? 把上面的问题抽象一下，设若有一个计算奖金的对象，现在需要能够灵活的给它增加和减少功能，还需要能够动态的组合功能，每个功能就相当于在计算奖金的某个部分。
?????? 现在的问题就是：如何才能够透明的给一个对象增加功能，并实现功能的动态组合呢？
?
?
?
未完待续
?
转载自：http://chjavach.iteye.com/blog/767739
