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

用groovy吧。用几个脚本文件工资计算策略

   工资变动和人员类别共同形成一种算法，不能分离组合。才不能用合成组合等方式。或者用13＋16个类的话，里面的方法就是208个了。

看来这个问题中确实是存在着208种算法，那么要简化，就得分析这208种算法有什么样的共同点。

比如说，如果很多算法都只是对每一种工资分别应用一个表达式进行计算，那么这些算法都可以用一个类来表示。

当然，这基本还是规则引擎的思路，就是用规则或者动态语言，而不是Java语言来描述这些算法。

“一个工资系统，有13种人员，每种人员有４种不同的工资组成，而对所有种类的人员，有１６种工资变动。 "

麻烦把需求描述清楚先！

UseCase是计算某个一人某个月的应得工资？13种人还是13个工资级别？（是否需要考虑人与工资的解耦？），每种工资级别都有4种工资组成or总共4种;......

不是很难啊

人作一个接口
四个属性
十三个方法

共十三个子类实现
每种人一种

工作量很少啊。。。

非常想问问模式这东西是不是为了让问题复杂化的？

所以我会用：
所有的工资变动都有可以分解为(money*X+Y)
将变动的208种可能一一列出并算出X，Y是多少
存在数据库中

用属性做吧，向楼上说的那样，把这种信息作为单独的一张表（比如salary表）放在数据库中，用的时候取出来就可以了

很想知道这个需求是怎样的，真有那么多规则？

策略模式不是一定要用在工资的算法上吧，遵循单一职责原则把算法抽离出来，用策略模式来封装对算法的调用。类的个数(sub级别的)13×4＋16

    不好意思,我说得不太清楚.工资变动和人员种类是作为算法规则的条件的.比如工资变动是"职务变动",人员种类是"工人",工资组成成分是岗位工资,级别工资,特殊津贴,保留津贴,这样需要由工资变动是职务变动,人员是工人,由工人的工龄,工人的级别(普通工,技术员,高级工......),分别求出工资的组成成分岗位工资,级别工资,特殊津贴,保留津贴.
    有16种类似"职务变动"的工资变动,13种类似"工人"的人员,比方说"首席执行官",这样算来,一种算法一个类的话就有16×１３种类了。
　　假如有1６个职务变动的类，　１３个人员种类的类，那么人员种类的类中，每种算法作为一个函数分开，就有　16×１３×４个方法了。

再说清楚点。
1.“工人”和“首席执行官”的区别是什么？
2.“职务变动”和“满年加薪”（我瞎猜的）的区别是什么？