熟悉Head First的书（事实上，认为它很精彩），虽然有时让我对模式重叠有点困惑。但是之前并没有真正尝试过坐下来将理论模式与现实世界的要求相匹配。
嗯，我们现在有一个要求，我认为我们应该考虑模式。我们的客户销售一系列产品，所有这些产品都可由客户高度配置。对于每次销售，我们需要捕捉客户对宽度，高度，颜色和一堆其他技术内容的选择。从广义上讲，这些产品在所有这些数据方面都有80％的相似性，但它们的差异足以使其变得复杂。
这感觉就像一个“经典”的要求，这就是为什么我在想模式。是......呃..策略模式？或者装饰师？如果不是，那是什么模式？
如果您需要知道我们将如何处理客户的选择......这将有助于计算成本价格，影响佣金等。这些操作对于每个产品而言大致会以相同的方式运行但是在某些情况下，可能因产品而异。
我们曾尝试过一次通过简单地对产品进行子类化来实现这一点并且它变得混乱并且该项目的一部分被放弃了。我们的无能解决方案在头版第一本书中被描述为在前五页内的一个基本错误{blush}。
答案 0 :(得分：2)
听起来decorator pattern会很好用。
是的，我绝对喜欢Head First的书。看完之后，GoF对我完全有道理。
答案 1 :(得分：2)
如果我正确理解了这个问题，你就有8个或9个单独的产品，我认为这些产品是某种类层次结构中的单个类。根据用户输入，您需要对这些类应用某些额外的逻辑，如计算成本价格，影响佣金等。
由于后者是运行时行为，因此使用继承来实现这种额外的逻辑确实不是一个好主意，因为最终会在每个产品类下面创建一些几乎相同的子类层次结构。
我不确定您提及的附加功能是否需要通过产品类本身的方法来访问，但如果是这样，Decorator将不适合作为被包装的对象装饰器不知道它被包装，因此不能调用它的包装器。如果调用者只需要附加行为，那么装饰器可能是一个选项，但它似乎仍然不适合我。
Strategy pattern似乎更适合您的问题。例如，当用户选择不同的方式来计算成本价格时，您只需在产品对象上设置ICostCalculator的不同策略实现，从而对产品行为的这个特定方面进行运行时更改。在我看来，这正是你正在寻找的。