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

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

　　　请赐教！！！　

我觉得除非LZ能把完整的计算规则贴上来，否则现在这样LZ象挤牙膏一样每次说一点点，讨论起来太累。

这个什么企业，设计那么复杂的工资制度？

建议还是把需求剪切出来，看看原始需求，不然大家也不知道这个13、16是物理存在实体的个数还是你归纳后的，可再推敲一下是否有更多的共性，更有利于大家讨论这个问题。

　　不好意思啊，因为牵涉到保密的问题，所以不能送上所有的规则。我以为只要表达好意思讨论技术就行了，其实上面的人员种类的工资组成也不是４种，人员种类不同，工资组成也不同。实在是抱歉了！

正应着教主那句话，所谓业务逻辑就是业务没有逻辑。
直觉是很难办。也许去探探客户真正的想法会有所收获。若是按照这个样子……呵呵。

如果真的是208种那么在实际中一定用不上
因为没什么人能无误记下那么多东西

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

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


这种方法与我想的刚好反了过来。。。。。。
不过用数据字典的话
可以减少很多代码
减少很多可能的错误
修改性也强多了。。。
难度上升是免不了的。

我也只是凭空猜想……不过就像楼上某人说的，没有人能记住那么多复杂的东西，也不大可能很平均地使用这么一个复杂的矩阵（甚至根本就不是矩阵，是N维空间点阵）。他们平时的使用中很可能有一些常见的模式，可能90%的操作都集中在10%的功能上。这个需求我直观看起来感觉很像是直接从原来的人工查询表格的模式套进来的，也许可以帮他们找到一种更好用的工作模式也不一定。