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

以下是关于班级等级的两分钱：

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

这通常意味着您只有一个类可以继承，但您偶尔可以获得两个甚至三个基类。不要完全避免多重继承，它可以是一个很好的工具来解决一些棘手的情况，但尽量减少它的使用。
还应避免深度继承层次结构。他们倾向于通过在多个不同的头文件中有效地拆分类定义来混淆接口，迫使你读取所有直接和间接基类声明来弄清楚类可以做什么。
可能出现的另一个问题是，您获得了太多普遍使用的类，这导致类之间的相互作用过于复杂。应该将类分组到连接良好的集群/模块中，只有一个非常小的接口，从该集群外部使用。

在这方面，模块的工作方式有点像在类之上的另一种封装方式，允许您将公知的类列入候选名单。但是，模块在C ++中是非正式的。它们可能对应于源树中的目录，但这既不是对模块的要求，也不是目录的存在是否包含模块的良好提示。但是，很好地记录您的模块。
但是，最重要的是，每个类都应该提供一个清晰简洁的界面，尽可能在使用它的客户端代码中使用它。它应该完成一项任务，并且做得很好。如果类需要做复杂的事情，它可以在幕后使用其他类（作为模块的代理），但它的界面应该尽可能简单。

在C ++中用OOP和多重继承理解好习惯

1 个答案: