这个多重继承的例子在C ++中是否可以接受?

时间:2012-06-19 23:47:22

标签: c++ multiple-inheritance

我有两个(不相关的)课程。第一个是“点”:

typedef std::complex<double> complex_number;

class Point
{
public:
    Point(const complex_number &affix);

    const complex_number & get_affix() const;
    void set_affix(const complex_number & new_affix);

    // etc
private:
    complex_number affix_;
};

(顺便说一句,很抱歉问这个无关的问题,但是在哪里放置我的类型定义?在这里,我的point.hpp文件的顶部,“良好实践”?)

第二个是“Abstract_Vertex”(这意味着以后是抽象图的一部分):

typedef int vertex_label;

class Abstract_Vertex
{
public:
    Abstract_Vertex(const vertex_label &label);

    const vertex_label & get_label() const;
    const vertex_label & get_neighbor_label(const int &index) const;
    void set_label(const vertex_label &new_label);

    bool is_neighbor_label(const vertex_label &label) const;

    // etc
protected:
    vertex_label label_;
    std::vector<vertex_label> neighbor_labels_;
};

现在我要创建第三个类“Plane_Vertex”(位于平面某处的顶点)。我正在考虑两种方法:

  1. 多重继承:Plane_Vertex类继承Point和Vertex,并且没有任何成员

  2. Plane_Vertex类仅从Vertex继承并拥有私有Point point_成员。

  3. 当然,我可以很容易地避免多重继承而只是选择2.但我是一个很好的小认真的C ++学习者,我想知道在我的情况下会有什么“好的做法”。

    感谢您的见解!

2 个答案:

答案 0 :(得分:1)

可能有第三种选择。您可以像标准库那样执行,并使AbstractVertex成为模板。然后,您可以在模板中实现图形导航和通用功能,并让用户提供值作为模板参数存储在节点中。

由于设计妥协,我将指出与我的观点存在的主要差异。

相关/不相关的顶点类型

在模板方法中,不同的实例化是完全不同的类型。这意味着Vertex<int>Vertex<Point>无关。另一方面,在上面的多态方法中,所有顶点IntVertexPointVertex ...都是AbstractVertex个对象:您可以将它们组合在容器中并连接它们或在代码中交替使用它们可以使用AbstractVertex。无论这是一种限制还是两种方法的优势,都是一种设计决策。我更喜欢这些类型不相关,因为我觉得你不应该混合这些类型。

要编写的代码量

在模板方法中,您实现模板,然后您只是实例化,在多态方法中,您需要为要包含在图形中的每个可能元素提供一个新类

如果最后你决定采用多态方法(我不愿意),那么我会避免使用两种类型的多重继承,并且更喜欢组合。一般来说,继承可能是面向对象语言中最容易被滥用的特性,它可以用来解决许多问题,有时它似乎是 all 最简单的解决方案,但是它不是。特别是你的基类型似乎都没有设计用于继承,没有任何功能可以被派生类型覆盖,没有虚函数。这些都清楚地表明你在构成足够的时候滥用继承。

答案 1 :(得分:0)

通常,除非您有充分的理由进行多重继承,否则请避免使用它。

原因:

  1. 您可以避开diamond problem
  2. 保持设计尽可能简单 - 在几个级别之后,多重继承可能真的很难跟进和维护。
  3. 当您不使用多重继承时,通常更容易检查您的班级是否满足良好设计的SOLID原则。
  4. Composition和/或aggregation通常会提供更好或更好的方法。
  5. 测试课程更容易。
  6. 这些应该足以让你入门。 Jon Cage所关联的帖子中有更多的智慧。

    因此,回答你的问题:看起来你没有足够的理由使用多重继承。使用组合。