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

楼主不能向大家提供明确需求，恐怕是没有确切的解决方案了，除非能猜测出你的“隐含需求”。
先不要管设计模式，不妨这样考虑：设计模式是设计的结果。
GOF模式就那么23种，实际模式不计其数，你设计的目标无非是一定的重用度、易于修改、易于维护。再加一个性能。
只要能做到以上几点，哪怕有200个类也是好模式（减压，放松思路）。（良好的分包、命名+一纸类索引、class mapping之类的就搞定，业务规则就有60页的东东，几页class mapping绝对值得。200个类了不起吗？ ）

临近假期，八卦细胞暴活跃，等节后看能不能给楼主提供详细的建议。

你说的2，3是下面的内容吧：

　　一：职务变动有低职务升到高职务，或者受处罚降级。同一种类人员不同的职务对应不同的档次级别，职务变动算法规则条件是“职务变动”，人员种类不同的属性信息，如工作年限，任本职务年限等。
　　二：确实有“年满加薪”，但还不在这１６种变动中，是另外一种算法。我就举有的“学历变动”吧。博士，硕士转正定级对应不同的职务级别，要与应聘的职务的工资各组成部分比较，取高的作为“学历变动”后的工资，比如应聘职务是部门经理，对应的职务工资档次是６，而按学历“硕士”转正定级对应的职务工资档次是７，那么选择７为工资档次，再查询数据库找对应的工资额。　

假如是，我举个例子吧：　　　
上面的
“特殊津贴
{
  getBy("档次")
}”只需要有档次就可以查询相应的工资标准表了，可以查出特殊津贴工资额。但是档次是未知道的。算法规则主要是在求档次上，如职务变动后的特殊津贴档次就是根据“职务变动日期”，“原档次”“学历”、“新任职务”、“原任职务”，“工作年限”，“任职年限”等求出的。

员工{”职务变动日期“，“原档次”，“学历”，“新任职务”，“原任职务”，“工作年限”，“任职年限“}

工资组成项{N种，每人只有其中的几种}

工资变动类型{N种，变动的时候肯定在这N种之内}

工资记录{员工，变动前工资 ，变动类型，变动后工资，变动后工资组成项集合}（取最新一条作为现在工资）

工资计算{员工，工资变动类型}

感觉就是从员工的信息 ，得到工资组成，在根据要么是职务，要么是以前的工资等来计算每项工资的实际金额，然后得出总金额，需求没见得多么复杂呀？不管规则怎么多，有些标准肯定要定下来吧 比如工资s=x*y
y经计算为80% 那么x总得是定下来的吧

现实总是不规则的。。。。。60多页的特殊场合。。。

不知道lz的系统中工资制度是不是定职的。

可以把这个数据和算法分离，在这里

数据 ： 工资的基本组成，档次，各个组成部分的金额。
算法：各个不同职务的工资算法＋职务变动的算法。

比如，员工A的工资中数据部分包括：基本工资，奖金，补贴。
A是一名工程师，那么其工资算法就对应工程师职务的算法。

当A的工资进行了调整，但是职务未变动，那么根据对应的只需要修改对应的工资数据部分就可以了。

如果A进行了职务调整，那么就要根据职务变动算法来调整数据，同时也替换A的工资算法。

这样下来，就是线性的增长，而不是乘积增长。而且在计算工资的时候，只需要本身工资基本数据＋对应的职务工资算法就可以了。仅仅是在职务变动的时候才需要职务变动算法。

建立两元矩阵，加上其它属性建立n元矩阵，肯定玩不转了,先要搞清楚规则才行。

   举个例子啊：
　　员工有１３种，每种有不同的职务系列，如普通工人、技术工人、专业技术工人......,普通工人有初级工、中级工、高级工，技术工人有初级技术员、中级技术员、高级技术员，专业技术工人有初级工程师、中级工程师、高级工程师。现在发生了职务变动，那么普通工人的职务变动算法和技术工人的职务变动算法就不一样，这样就有１３种算法了，有１６种变动，就有１６×１３这一说了。当然其中有些规则可以抽象出来共用的，不过１６＋１３是肯定搞不定的。

员工信息中涉及到工资的字段 都可以作为关键字
我们可以以这些参数为基础构造一套规则，原理上类似于SQL，HQL，MDX 这些语言（远未那么复杂吧），然后每遇到员工的一项工资组成的时候，我们可以根据定义好的规则进行解析计算 最后得到总工资。



标准是指 以关键字为主体的一些涉及工资的金额等信息 可以说是工资系统的 系统设置表 了


这样处理的话，我觉得有点类似 我们以前常用的 动态生成sql语句来进行我们的数据库操作，只不过这里的“sql语句”需要你们自己来实现了

对工资的计算,建议可以采用规则引擎来实现

建议 把规则放入数据库中，存储过程实现也不错！