【问题标题】:Improving a C++ class architecture where many classes derive from the same two bases改进 C++ 类体系结构,其中许多类派生自相同的两个基础
【发布时间】:2013-10-22 14:41:06
【问题描述】:

我有一个 C++ 架构,其中有许多类都派生自两个不同的基类。所有派生类都以略有不同的方式覆盖/实现基类中的相同方法。举例说明:

class B1 {
public:
    // method_1 is pure virtual.
    virtual void method_1() = 0;
};

class B2 {
public:
    // method_2 is not pure virtual.
    virtual void method_2();
};

class D1 : public B1, public B2 {
public:
    virtual void method_1() { // Does something... }
    virtual void method_2() { // Does something... }
};

class D2 : public B1, public B2 {
public:
    virtual void method_1() { // Does something slightly different... }
    virtual void method_2() { // Does something slightly different... }
};

一切正常,但是由于有大约 20 个派生类,感觉应该是一种改进这种设计的方法,这样我就必须编写更少的代码,尤其是作为派生类他们所做的事情通常非常相似。谁能给我一些关于未来的建议?

【问题讨论】:

  • 它们都继承自B1 和B2 吗?然后,您可以先将 B1 和 B2 替换/合并为单个类 B。
  • method1一般可以用method2来实现吗?
  • @Axel 它们都继承自B1 和B2,所以我可以这样做。但我的直觉说这很糟糕,因为这两个基地是不同的——我会在@Alexander L. Belikoff 的回答中添加更多内容。 @Matteo,我不这么认为。
  • 为什么有这么多相似的类?
  • 我认为第一个问题是D1和D2之间的区别是否可以通过某种方式进行参数化。

标签: c++ architecture


【解决方案1】:

看看策略设计模式。基本上将方法 1 和 2 包装在 B1 和 B2 类上,这些类由 D 类的唯一指针拥有。然后您可以在 D 的构造函数中传递 B1 和 B2 实例。

【讨论】:

  • 这看起来可能是一个选项。您能否详细说明一个实现,因为虽然我可以找到对该模式的体面解释,但该方法对我来说有点抽象(请原谅双关语......)
  • 我implemented the pattern,虽然我可以看到通过接口实现所有选项的设计优势,但我不得不在这里编写更多代码,而不是更少。嗯。
  • 更少的代码不一定意味着更好的可维护性/灵活性/等等。在这种特殊情况下,当您的类 D 具有相同的 function_1() 但不同的 function_2() 时,使用两种策略而不是多重继承可能会很有用。否则没有直接的好处,但是除非你有充分的理由不这样做,否则优先考虑组合而不是继承被认为是好的。阅读此parashift.com/c++-faq/mi-not-evil.html 以获得良好的概述。
【解决方案2】:

如果不知道你的实现的领域(即你的程序究竟试图做什么),几乎不可能分析或建议一个更好的设计模型)。在这里做一个非常广泛的陈述,很少有使用一般形式的多重继承(即除了通过接口继承行为)是合理的情况。同样,这是一个笼统的声明,仍然有一些例外,具体取决于域。

【讨论】:

  • 很公平。域(我想)是嵌入式处理器上的菜单系统。 B1 是所有Ds 实现的抽象回调类。 B2 是一个服务类,它在没有 RTOS 的情况下模拟任务环境。所有Ds 都是“菜单选项”,用户可以选择它们来做一些独特的事情。
  • 嗯...那你真的需要从B2继承吗?在这种情况下,也许使用它而不是继承它会更干净?在这种情况下,您只有一个“菜单回调”类可以继承。
  • 我想我会这样做(鉴于我目前的设计),否则我看不到让每个菜单选项由底层硬件计时器“服务”的简洁方法?感觉就像我会在没有派生的情况下将不必要的网关引入Ds?如果我不派生,我将如何影响派生类而不引入一些其他接口(和更多代码)?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-05-04
  • 2011-12-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多