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

首先不要去套用设计模式，这样会把你自己的设计思路，需求，背景等等打乱，应该按照oo设计原则，封装可变的，提取共性和可变性。在分析阶段，你可以采用下“分析矩阵”，这样在多个对象交互的时，可以提取他们的共性和可变性，更重要的是把他们的关系理解清楚。

企业人的职业种类： p1 p2 p3 p4 .......
企业工资规则    ： a1 b2 c3 d4
                a1 b2 c3 d4
                a1 b2 c3 d4


不知道是否表达清楚？？

笔者认为algorithm 使用策略模式是合适的！在Change和Argith之间使用桥接模式。就不会出现上述208类的问题。在具体编码实现时，要用到工厂模式！下面画出主要示意图：

我正在学习设计模式，怎么看楼主的问题跟Thinking in Patterns 中的一个例子很相像，例子中用的是Decorator。详情见：

http://java.learndiary.com/disDiaryContentAction.do?goalID=2711

Thinking in Patterns下载地址：
http://www.mindviewinc.com/downloads/TIPatterns-0.9.zip

这应该不是Decorator的问题,这是个排列组合的问题吧,应该是对逻辑算法进行抽象 而不是确切的用户实体了

直觉告诉我不是什么复杂的问题。
估计你做的系统使用单位的人员至少有20万
而且行政管理人员的数量超过10%

如果每一种人员都有16种工资变化，（清洁工也会有16种），即16种是固定的话，使用 桥梁模式，如果16种不固定，比如有的只有2种，其他的有6种，使用策略模式中嵌套策略模式。至于工资由4部分组成，使用装饰模式。但这里这个问题使用模式也不能很好的解决问题，应当考虑反模式，规则引擎是比较明智的选择

同意楼上的，一般这种排列组合式的都可归纳为继承或者桥接，种类少了用继承＋策略模式，这样就会出现楼主说的208种；多了用桥接＋策略，可以出现13 + 16个类

哈哈哈，这个系统肯定是给政府/央企用的。
相信这个时候楼主已经把问题解决了。
比这个需求复杂的都有的。

不过显然楼主被自己的16*13吓坏了。16*13不一定比1大哦，呵呵。