我经常有一个类,我希望允许选择一个功能。例如,我有一个具有GetNextNode()
函数的类,其使用方式与MyClass::DoIteration(){GetNextNode(); }
类似。我想允许用户从GetNextNode的许多可能实现中选择一个来确定应该如何确定要处理的下一个节点。我还想让我的代码的用户轻松提供他们自己的实现。
到目前为止,答案是让GetNextNode()
虚拟并重新实现它的MyClass子类......
当我有两个这样的可互换功能时,我的问题就出现了。如果我有Function1()
和Function2()
都有N个可能的实现,那么我将不得不提供2N子类以允许用户选择要使用哪一对这些函数。一般来说,情况要糟糕得多(如果有超过2个这样的功能)。
请注意,这些函数需要访问MyClass中的数据。
是否存在我缺少的“模式”,允许选择这样的“插件”?
答案 0 :(得分:3)
实际上,我认为他所寻求的是基于政策的设计,请参阅http://en.wikipedia.org/wiki/Policy-based_design。
编辑:
示例,(显然没有编译,但希望你明白了。你为IterationPolicy提供了一个模板参数,它应该是一个提供getNextNode函数的类。你可以提供一个默认策略和各种各样的与您的类一起使用替代策略。如果用户实现了适当的接口,用户也可以编写自己的策略。避免与继承相关的问题。
template <typename IterationPolicy = DefaultIterationPolicy>
class class X {
IterationPolicy iterationPolicy;
void DoIteration() { iterationPolicy.getNextNode(); }
};
答案 1 :(得分:0)
你看过visitor pattern吗?
答案 2 :(得分:0)
您可以将不同的实现提供为受保护的功能。
...
protected:
Node GetNextNode_Method1();
Node GetNextNode_Method2();
public:
Node GetNextNode();
...
最终的类可以覆盖GetNextNode()以应用其中一个提供的替代方案。
答案 3 :(得分:0)
这看起来像Strategy Pattern编辑:如果您只需要编译时变化,那么您自己发现的Policy-based design可能更合适。
class NextNodeStrategy {
public:
virtual int GetNextNode() = 0;
};
class MyClass {
private:
NextNodeStrategy &nextNode;
public:
void SetNextNodeStrategy(NextNodeStrategy &strategy)
{
nextNode = strategy;
}
void DoIteration()
{
nextNode.GetNextNode();
}
};
该策略可能需要访问其他内容,因此您可能需要将某些内容传递给GetNextNode,现在该实现位于separte类中,并且您可能希望提供它的默认实现(例如,只需让MyClass继承)来自NextNodeStrategy,并在MyClass构造函数中设置nextNode = this
;
如果你还有其他东西也可以改变,你也可以制定一个策略,2可以独立改变。