提问：使用策略模式的烦恼，要实现２０８个类

第一个问题：
　　一：工人的工资组成是岗位工资,级别工资,特殊津贴,保留津贴。首席执行官的工资组成是职务工资，薪级工资，特殊津贴,保留津贴。
　　二：　工资组成中，特殊津贴因职务（工人、首席执行官）不同，有不同的特殊津贴档次，每个档次对应不同的工资额。其余工资组成间的差别与此类似。
第二个问题：
　　一：职务变动有低职务升到高职务，或者受处罚降级。同一种类人员不同的职务对应不同的档次级别，职务变动算法规则条件是“职务变动”，人员种类不同的属性信息，如工作年限，任本职务年限等。
　　二：确实有“年满加薪”，但还不在这１６种变动中，是另外一种算法。我就举有的“学历变动”吧。博士，硕士转正定级对应不同的职务级别，要与应聘的职务的工资各组成部分比较，取高的作为“学历变动”后的工资，比如应聘职务是部门经理，对应的职务工资档次是６，而按学历“硕士”转正定级对应的职务工资档次是７，那么选择７为工资档次，再查询数据库找对应的工资额。　　

　　　请赐教！！！　

　　　说的很经典，谢谢了。这个确实是客户需要达到的要求，是用户的真正需求。以前已经有一个完成这样目标的系统，不过是ＣＳ架构的，达到了上述需求。现在简单化了大部分的业务规则，要求用ＢＳ架构来作。
　　　原来系统的办法就是１６种变动，对应１６个类，每个类中有几个算工资组成的函数，每个函数中有１３个因人员种类不同而写的ｉｆ，ｅｌｓｅ。
　　　现在我正在这些规则中，抽象公用的东西，想在算法中实现引用复用。
　　　
　　　这个项目也算是对我们的考验吧！！！

先按照原来的写，写的过程中进一步熟悉业务逻辑，然后再重构，不用一步到位吧。

看来lz是被策略模式套牢了！从一开始打定用该模式，然后为了套这个模式而套这个模式！

看了半天，直觉用决策表就可以搞定的，不过你的需求实在是太少！

　　业务逻辑已经整理出了，现在就是写概要设计的时候，将来要写详细设计。所以现在想尽可能少的压缩策略类，尽量将相同的东西抽象出来。设计方式是这样一层一层的用策略模式了，现在就是看是否有其它的方法修改一下这种策略模式要很多类的设计方式，少写一些类，又达到用策略模式的优点。
　　

同意