我知道继承钻石被认为是不好的做法。但是，我有两个案例，我觉得菱形继承(钻石问题)非常适合。我想问一下，你会推荐我在这些情况下使用菱形继承(钻石问题)，还是有其他更好的设计。

案例 1: 我想在我的系统中创建代表不同类型“操作”的类。 Action 按几个参数分类:

• Action 可以是“读”或“写”。
• Action 可以有延迟也可以没有延迟(它不仅仅是一个参数。它会显着改变行为)。
• Action 的“流类型”可以是 FlowA 或 FlowB。

我打算有以下设计:

// abstract classes
class Action  
{
    // methods relevant for all actions
};
class ActionRead      : public virtual Action  
{
    // methods related to reading
};
class ActionWrite     : public virtual Action  
{
    // methods related to writing
};
class ActionWithDelay : public virtual Action  
{
    // methods related to delay definition and handling
};
class ActionNoDelay   : public virtual Action  {/*...*/};
class ActionFlowA     : public virtual Action  {/*...*/};
class ActionFlowB     : public virtual Action  {/*...*/};

// concrete classes
class ActionFlowAReadWithDelay  : public ActionFlowA, public ActionRead, public ActionWithDelay  
{
    // implementation of the full flow of a read command with delay that does Flow A.
};
class ActionFlowBReadWithDelay  : public ActionFlowB, public ActionRead, public ActionWithDelay  {/*...*/};
//...

当然，我会遵守没有 2 个 Action (从 Action 类继承)将实现相同的方法。

案例 2: 我在我的系统中为“命令”实现复合设计模式。一个命令可以读、写、删除等。我也想有一个命令序列，也可以读、写、删除等。一个命令序列可以包含其他命令序列。

所以我有以下设计:

class CommandAbstraction
{
    CommandAbstraction(){};
    ~CommandAbstraction()=0;
    void Read()=0;
    void Write()=0;
    void Restore()=0;
    bool IsWritten() {/*implemented*/};
    // and other implemented functions
};

class OneCommand : public virtual CommandAbstraction
{
    // implement Read, Write, Restore
};

class CompositeCommand : public virtual CommandAbstraction
{
    // implement Read, Write, Restore
};

此外，我还有一种特殊的命令，“现代”命令。一个命令和复合命令都可以是现代的。成为“现代”会为一个命令和复合命令添加特定的属性列表(它们的属性大多相同)。我希望能够持有指向 CommandAbstraction 的指针，并根据所需的命令类型(通过 new)对其进行初始化。所以我想做下面的设计(除了上面的):

class ModernCommand : public virtual CommandAbstraction
{
    ~ModernCommand()=0;
    void SetModernPropertyA(){/*...*/}
    void ExecModernSomething(){/*...*/}
    void ModernSomethingElse()=0;

};
class OneModernCommand : public OneCommand, public ModernCommand
{
    void ModernSomethingElse() {/*...*/};
    // ... few methods specific for OneModernCommand
};
class CompositeModernCommand : public CompositeCommand, public ModernCommand
{
    void ModernSomethingElse() {/*...*/};
    // ... few methods specific for CompositeModernCommand
};

再次，我将确保没有 2 个继承自 CommandAbstraction 类的类将实现相同的方法。

谢谢。

最佳答案

继承是 C++ 中第二强(更耦合)的关系，仅次于友元。如果您可以重新设计为仅使用组合，您的代码将更加松散耦合。如果你不能，那么你应该考虑你的所有类是否真的应该从基类继承。是由于实现还是只是一个接口(interface)？您想使用层次结构中的任何元素作为基本元素吗？或者只是你的层次结构中的叶子是真正的行动？如果只有叶子是 Action 并且您正在添加行为，则可以考虑针对此类行为组合进行基于策略的设计。

这个想法是可以在小类集中定义不同的(正交的)行为，然后将它们捆绑在一起以提供真正完整的行为。在示例中，我将只考虑一个策略，该策略定义是现在还是将来执行操作，以及要执行的命令。

我提供了一个抽象类，以便模板的不同实例可以(通过指针)存储在容器中或作为参数传递给函数并以多态方式调用。

class ActionDelayPolicy_NoWait;

class ActionBase // Only needed if you want to use polymorphically different actions
{
public:
    virtual ~Action() {}
    virtual void run() = 0;
};

template < typename Command, typename DelayPolicy = ActionDelayPolicy_NoWait >
class Action : public DelayPolicy, public Command
{
public:
   virtual run() {
      DelayPolicy::wait(); // inherit wait from DelayPolicy
      Command::execute();  // inherit command to execute
   }
};

// Real executed code can be written once (for each action to execute)
class CommandSalute
{
public:
   void execute() { std::cout << "Hi!" << std::endl; }
};

class CommandSmile
{
public:
   void execute() { std::cout << ":)" << std::endl; }
};

// And waiting behaviors can be defined separatedly:
class ActionDelayPolicy_NoWait
{
public:
   void wait() const {}
};

// Note that as Action inherits from the policy, the public methods (if required)
// will be publicly available at the place of instantiation
class ActionDelayPolicy_WaitSeconds
{
public:
   ActionDelayPolicy_WaitSeconds() : seconds_( 0 ) {}
   void wait() const { sleep( seconds_ ); }
   void wait_period( int seconds ) { seconds_ = seconds; }
   int wait_period() const { return seconds_; }
private:
   int seconds_;
};

// Polimorphically execute the action
void execute_action( Action& action )
{
   action.run();
}

// Now the usage:
int main()
{
   Action< CommandSalute > salute_now;
   execute_action( salute_now );

   Action< CommandSmile, ActionDelayPolicy_WaitSeconds > smile_later;
   smile_later.wait_period( 100 ); // Accessible from the wait policy through inheritance
   execute_action( smile_later );
}

继承的使用允许通过模板实例化访问策略实现中的公共(public)方法。这不允许使用聚合来组合策略，因为不能将新的函数成员推送到类接口(interface)中。在示例中，模板依赖于具有 wait() 方法的策略，该方法对所有等待策略都是通用的。现在等待一个时间段需要一个固定的周期时间，通过 period() 公共(public)方法设置。

在示例中，NoWait 策略只是时间设置为 0 的 WaitSeconds 策略的一个特定示例。这是有意标记策略接口(interface)不需要相同。通过提供一个注册为给定事件回调的类，另一种等待策略实现可能是等待若干毫秒、时钟滴答或直到某个外部事件。

如果您不需要多态性，您可以从示例中完全取出基类和虚方法。虽然对于当前示例来说这可能看起来过于复杂，但您可以决定将其他策略添加到组合中。

虽然如果使用普通继承(使用多态性)，添加新的正交行为将意味着类的数量呈指数增长，但使用这种方法，您只需分别实现每个不同的部分，然后在 Action 模板中将它们粘合在一起。

例如，您可以定期执行操作并添加退出策略来确定何时退出周期性循环。首先想到的选项是 LoopPolicy_NRuns 和 LoopPolicy_TimeSpan、LoopPolicy_Until。这个策略方法(在我的例子中是 exit())为每个循环调用一次。第一个实现在一个固定的数字(由用户固定，如上例中固定的周期)之后计算它被称为退出的次数。第二种实现将在给定的时间段内定期运行该进程，而最后一种实现将运行此进程直到给定的时间(时钟)。

如果你还跟着我到这里，我确实会做出一些改变。第一个是，不是使用实现方法 execute() 的模板参数命令，而是使用仿函数，可能还有一个模板化的构造函数，它将命令作为参数执行。基本原理是，这将使其与其他库(如 boost::bind 或 boost::lambda)结合起来更具可扩展性，因为在这种情况下，命令可以在实例化时绑定(bind)到任何自由函数、仿函数或成员方法一类的。

现在我得走了，但如果你有兴趣，我可以尝试发布修改后的版本。

关于c++ - 菱形继承(钻石问题) (C++)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/379053/