扩展策略模式：添加Context方法和子类

Question

  

strategy pattern定义了一系列算法，将每个算法封装起来   一，并使它们可以互换。策略让算法变化   独立于使用它的客户。

非常好。但请考虑这种情况：我有一个策略模式，其中包含一些上下文子类和一些算法，如下所示。代码应该在最后关闭以进行修改，但我仍然需要能够实现以下可扩展性。无需更改现有代码：

1. 向使用策略的Context添加新方法
2. 添加Context
的新子类型



我想到Visitor，这对于实现1）是有益的。但是添加新的Context子类型需要对所有Visitor进行更改，因此这不起作用。

Decorator怎么样？通过装饰Context，您可以添加新方法。但我真正需要的是添加具体实现的方法，这些方法可以像策略模式一样变化。

您如何看待，如何实现这一目标？

祝你好运

richn

修改

这是一个具体的例子。

我应该解释一下：我有一个带有模拟窗口的应用程序，显示了不同种类的VisibleObject和另一个窗口来控制这些对象。 VisibleObject的状态需要在使用策略的模拟中反映出来。例如，如果我禁用Polygon，则应将其隐藏在模拟中，或者完全删除，具体取决于具体DisablingBehavior。

如果定义了一种新的VisibleObject，比如说Picture，我希望所有现有的DisablingBehaviors和PositioningBehaviors能够处理它。

如果有新的操作，比如MirrorObject()，则需要在VisibleObjects上执行，我希望能够定义MirroringBehaviors之类的不同AxisMirroring行为或PointMirroring并将其分配给VisibleObject s。

Answer 1

设计模式并未涵盖所有情况。你不应该盲目地遵循某种模式，或者试着让你的软件适合某些模式。以下是罗伯特C.马丁书的引用：

  

通常，它们是在没有展示代码如何演变使用的情况下呈现的   模式。这可能会让您认为模式很简单   您以完整的形式插入代码和设计中的内容。   这不是我的建议。相反，我更愿意改进我的代码   在模式的方向上工作。我可能会达到这种模式，或者   我可能不会。

Answer 2

看起来你可能需要的是一个Bridge模式：http://en.wikipedia.org/wiki/Bridge_pattern。

它不会“保护”您添加新方法。我非常肯定在这种情况下没有任何模式可以帮助。当您向接口和/或基类添加公共方法时，您正在修改（不扩展！）必要的合同，并带来所有后果。