Question

我熟悉《头脑优先》这本书（事实上，我认为它很精彩），尽管有时它会让我对重叠的模式感到有点困惑。但之前并没有真正尝试坐下来，将理论中的模式与现实世界的要求相匹配。

好吧，我们现在有一个要求，我认为我们应该从模式的角度来思考。我们的客户销售一系列产品，所有这些产品都可以由他的客户高度配置。对于每次销售，我们都需要了解客户对宽度、高度、颜色和一系列其他技术内容的选择。总体而言，就所有这些数据而言，这些产品有80%的相似性，但它们的差异足以使其变得复杂。

这感觉像是一个“经典”要求，所以这就是我思考模式的原因。是不是。。。呃。。战略模式？或者可能是装饰师？如果不是，是哪种模式？

如果您需要知道我们将如何处理客户的选择。。。这将有助于计算成本价格、影响佣金等。这些操作对每种产品的工作方式大致相同，但在某些情况下，可能因产品而异。

我们之前曾尝试过通过简单地对产品进行子类化来实现这一点，但结果变得一团糟，项目的这一部分被放弃了。我们的笨拙解决方案在《头脑优先》一书中被描述为大约前五页内的一个基本错误。

Answer 1

如果我正确理解这个问题，你有8或9个独立的产品，我认为它们是某种类层次结构中的单个类。根据用户输入，您需要将某些额外的逻辑应用于这些类，如计算成本价格、影响佣金等。

由于后者是运行时行为，因此对这个额外的逻辑使用继承确实不是一个好主意，因为您最终会在每个产品类下创建许多几乎相同的子类层次结构。

我不确定您提到的附加功能是否需要由产品类本身的方法访问，但如果需要，aDecorator不太适合，因为被Decorator包装的对象不知道它正在被包装，因此无法调用其包装器。如果额外的行为只由调用者需要，Decorator可能是一个选项，但对我来说似乎仍然不太适合。

策略模式似乎更符合您的问题。例如，当用户选择不同的方式来计算成本价格时，您只需在产品对象上设置ICostCalculator的不同策略实现，从而在运行时更改产品行为的这一特定方面。在我看来，这正是您想要的。

Answer 2

听起来像装饰器模式在这里会很好。

是的，我非常喜欢《头优先》这本书。看完之后，GoF对我来说完全有意义了。