【问题标题】:class/struct design; inheritance vs forward declaration类/结构设计;继承与前向声明
【发布时间】:2014-04-25 03:46:56
【问题描述】:

我无法理解何时/是否应该使用单/多继承与前向声明,我想在下面的示例中更好地理解它。如果有人能指出我正确的方向,或解释它们之间的差异,那将不胜感激。

以下是我正在处理的数据结构示例;

存在 1 个父、1 个子父和许多不同子类型。即每个父母每个子父母有很多孩子。一些子项需要访问其他子项对象。孩子们将使用彼此相似的功能,即 ParseSelf/Display/Save/Edit。如果子项发生更改(即编辑/保存),还需要更新子父项、父项和可能的其他子项中的数据。

我想知道实现这样的事情的最佳方法是什么?我在下面提出了两种选择。如果需要更多说明/信息,请告诉我。

class SubParent;
class Children;

class Parent
{
    ...
    int iParent;
    SubParent *pSubParent;
};

class SubParent
{
    ...
    int iSubParent;
    std::list<Children> childrenList;
};

class Children
{
    ...
    int iChild;
    int ChildType;
    char *pData;
};

对;

class Parent
{
    ...
    int iParent;
};

class SubParent : public Parent
{
    ...
    int iSubParent;
};

class Children : public SubParent
{
    ...
    int iChild;
    int ChildType;
    char *pData;
};

谢谢。

编辑: 家长的主要工作;维护有关文件的信息,即 SubParent 的位置、SubParent 大小、包括自身在内的所有数据的总大小。 SubParent的主要工作;包含有关儿童的信息,即儿童的大小和位置。 除了使这些项目保持最新之外,父/子父实际上并没有做太多其他事情。

【问题讨论】:

  • 您在谈论继承与组合。您没有向我们提供有关这些类应该做什么的足够信息,但您的第一种方法可能更好。跨度>
  • @Beta 我将编辑我的问题以添加额外的信息。
  • 不确定您要做什么。在编写任何类或接口之前,总是首先在 main 中编写示例用法代码。
  • 我没有看到任何暗示 Children 以任何方式“是”SubParent 或 Parent,所以我不明白为什么甚至会考虑继承.如果SubParent 应该包含std::list 的Children,则继承将无法替代它。这似乎是一个非常奇怪的案例。另一方面,如果您发现自己需要像ChildType 这样的成员,这可能表明多态性可能是这部分更好的解决方案。此外,您可以通过以相反的顺序定义您的类来避免第一个示例中的前向声明。

标签: c++ class inheritance forward-declaration


【解决方案1】:

我建议使用第一种方法,并进行以下更改:

  1. 在SubParent 中添加一个指向Parent 的成员。这将允许您双向遍历对象。

    class SubParent
    {
        ...
        int iSubParent;
        Parent* parent;
        std::list<Children> childrenList;
    };
    
  2. 如果您要拥有不同类型的Children,则应在SubParent 中保留Children* 的列表,而不是Chilren 的列表。如果Children 永远不会有任何子类,那么拥有Children 的列表就足够了。

  3. 在Children 中添加指向SubParent 的指针。同样,这将允许您以两种方式遍历对象。给定Children,您将能够通过该指针访问其兄弟姐妹。

    class Children
    {
        ...
        int iChild;
        int ChildType;
        SubParent* subParent;
        char *pData;
    };
    

【讨论】:

  • 如果类是逆序而不是使用前向声明,这种方式(即使用指针)是否仍然需要?
  • @ReturnVoid 我没有回答这个问题。
  • @R Sahu 没关系,在重读你的帖子几次后我明白了。
猜你喜欢
  • 1970-01-01
  • 2017-04-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-06-09
  • 1970-01-01
  • 2011-06-10
  • 1970-01-01
相关资源
最近更新 更多