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

我觉得很奇怪，会有这么复杂么？
手工还能算得清么？
我觉得手工算得话，应该只有几个规则和公式。
不用搞几百个类来实现这个吧？
我认为用嵌入脚本引擎的方式比较现实，将若干公式及规则用脚本来表达，既灵活，又简单。
规则引擎不熟悉，不做论断。

个人觉得这样的需求，不是算法复杂，而是算法涉及到的参数比较多。那最好就别用策略模式了，使用数据库做一些存放参数的表。甚至计算都可以写成存储过程，在java里面只要传递参数，调用存储过程，获取结果就得了。对数据的修改和SP的修改肯定方便过对程序的修改。

谢谢大家的方案，看来策略模式确实不太适合，现在正在尝试用表驱动方法及策略模式混合等方式试一试。
至于参数等（如工资标准等），现在用程序解决的，应用服务器启动的时候，都已经放在缓存中了。

说几句废话,

其实最重要的并不是用策略模式,用规则,用脚本.而是:需求.

你可以自己用认为最合适的语法,英语也好,自己假想中的语言也好,来试图最精确简洁地描述需求.


如果这个描述本身就根本无法简化,而必须写200种完全不相关的不同的逻辑,那么,没办法,需求就是这样复杂,你不可能无中生有把它变简单了.

而如果你可以用某些方式来简化这个描述,(比如,如果工龄大于50,则工资必须至少为工龄的十倍,这种不需要重复200次的逻辑),那么再考虑怎么用最好的方法实现.

肯定有什么地方不对。。。
程序一定有需求，谁会有这么复杂的需求？
难道客户会写２００多种不同的情况的需求？
我不敢相信财务部门会设计出来这么复杂的工资算法
这里面总是有规则的，而不是必须枚举全部的情况
是你们把简单问题复杂化了吧

  现在我也正在抽象相同的东西，规则确实比较多，光是政策规则就写了６０多页。

我觉得这种系统应该是 work flow（或者template)和 策略模式的
结合。
使用配置文件将多个小策略组合起来。
这样需要实现的类就少很多。

设计模式是要组合用的。

另外，webwork里的xwork是可以拿出来当flow管理用的。：）

同意buaawhl的建议，使用组合的方式就可以使用13+16=29个类进行实现。没有必要写208个类。

看得有点晕，不过很显然用规则引擎是比较合适的，直观，易修改，不然客户如果有一天要变下策略，估计维护代码的人会疯掉。

根据问题一的理解：
工人工资
{
     岗位工资 + 级别工资 + 特殊津贴 + 保留津贴
}

岗位工资{
  getBy("岗位")
}

特殊津贴
{
  getBy("档次")
}

保留津贴
{
  getBy("档次")
}

级别工资
{
  getBy("档次")
}


看不懂2,3是怎样影响工资的。