c++ - 了解 OOP 的良好习惯和 C++ 中的多重继承

Question

我最近了解到我还没有练习 OOP 中的最佳习惯，而是开始研究更好的 OOP 习惯。所以我的问题是——我应该将一个类继承的东西数量限制在一定数量吗？

一个例子来帮助解释。

注意:构造函数和析构函数已从示例中删除以节省空间。

class Object
{
 protected:
    /* common declarations */

 public:
    /* common functions */
}

class Collidable
{
 protected:
    /* common declarations */

 public:
    virtual void Collide() = 0;

    /* common functions */
}

class Animated
{
 protected:
    /* common declarations */

 public:
    virtual void Animate() = 0;

    /* common functions */
}

class Unit : public Object,  public Collidable, public Animated
{
 protected:
    /* common declarations */

 public:
    virtual void Collide() { /* Collide  */ }
    virtual void Animate() { /* Animate  */ }

    /* common functions */
}

这里，class Unit继承了它上面的三个类，我想知道的是，继承东西的时候应该限制多少？如 class Object : class, class, class... etc。是否应该将继承类的数量限制在较小的数量，并在其间创建已经继承了一些抽象基类的类？我知道这个问题有点无聊，但我希望保持良好的习惯，如果可以的话，我感谢你帮助我。

此外，任何其他关于 OOP 良好习惯的建议也将不胜感激。

Answer 1

这是我对类层次结构的两点看法:

1. 为可能出现在两个不同类中的每个虚函数定义一个接口(interface)类当然不是一个好主意。这些虚函数声明通常应该保留在主继承树中，除非您有充分的理由将它们分解。

   这通常意味着您只有一个类可以继承，但您偶尔可能会得到两个甚至三个基类。不要完全避免多重继承，它可能是解决一些棘手情况的好工具，但尽量减少它的使用。

2. 也应避免深度继承层次结构。它们倾向于通过有效地将类定义拆分到许多不同的头文件中来混淆接口(interface)，迫使您阅读所有直接和间接的基类声明以弄清楚一个类可以做什么。

3. 可能出现的另一个问题是您获得了太多通用类，这导致类之间的相互作用过于复杂。类应该被分组到连接良好的集群/模块中，只有一个非常小的接口(interface)可以从集群外部使用。

   在这方面，模块的工作方式有点像类之上的另一种封装方式，它允许您将公开已知的类列入候选名单。不过，模块在 C++ 中是非正式的。它们可能对应于源代码树中的目录，但这既不是模块的要求，目录的存在也不是一个很好的暗示它包含一个模块。但最好为您的模块做好文档记录。

4. 但是，最重要的是，每个类都应该提供一个清晰简洁的接口(interface)，该接口(interface)在使用它的客户端代码中尽可能有用。它应该完成一项任务，并且把它做好。如果该类需要做复杂的事情，它可以在幕后使用其他类(作为一个模块的代理)，但它的接口(interface)应该尽可能简单。