【问题标题】:Large abstract base classes大型抽象基类
【发布时间】:2011-10-10 13:09:45
【问题描述】:

我正在编写一个包含 30 个纯虚拟方法的大型抽象基类*。

在实现类中查找要在基类中实现的所有函数有点繁琐,主要是因为 MSVC++ 没有告诉你你没有实现哪个函数,编译器错误“无法构造抽象类” "

所以,我想知道我的大型抽象基类是不是一个坏主意,或者我应该把它分成几个接口,还是有一个编译器警告我可以激活它会告诉我哪个方法我没有提供实现......或者这只是抽象类编码的一部分,我应该习惯它。

*它的作用是在几个不同的渲染子系统之间提供一层通用功能。

【问题讨论】:

  • 我的 MSVC 确实告诉我哪些函数是抽象的。
  • 如果您可以将界面划分为清除组件,请执行此操作。我不会声称对此有充分的合理理由,但我认为这显然是一件好事。

标签: c++ class visual-c++ abstract base


【解决方案1】:

在我看来,接口类本质上是不好的,但是提出的问题使这个特定的应用程序听起来很可疑。

如果您有从该接口派生的类,并且不清楚您需要重写哪些函数,这似乎表明所有这些函数可能都不是必需的。

当你制作一个抽象基类时,纯虚方法的数量并不重要(对我来说),但应该清楚为什么从这个接口派生的每个类都必须实现每个纯虚函数。如果您发现自己在想“为什么我必须实现这个功能?”,将抽象类分解为几个不同的接口可能是合适的。

【讨论】:

  • 最后一段真正触及了问题的核心。
【解决方案2】:

反正这么大的课就是一团糟,神级的反模式。使用聚合/组合拆分一个类,看看 SOLID 开发原则,看起来单个类的 30 种方法不遵循单一职责原则,至少......所以我想建议重新考虑类的设计。祝你好运!

【讨论】:

    【解决方案3】:

    通常,在“无法实例化抽象类”错误(在调用它的行中抛出)之后,如果您在编写实现之前将接口复制并粘贴到类中,您将收到链接器错误“未解决的外部错误”指向您忘记实现的方法。

    【讨论】:

      【解决方案4】:

      这个问题没有明显的正确答案。决定是否将基类分解为多个抽象基类可能应该是您根据基类是否在逻辑上 表示几个不同的概念而不是根据糟糕的编译器错误消息做出的决定。如果您这样做的唯一原因是编译器错误消息,您可能需要检查是否可以升级编译器,或者是否有其他原因这样做。大多数现代编译器应该提供关于此的非常好的、详细的错误。

      如果您的设计表明您实际上可能希望拥有多个不同的类来实现基类的一小部分,则将接口拆分为多个部分可能是一个好主意。如果您希望这样做,则将接口分开可能是有利的。但是,您会从中看到一些额外的复杂性。例如,如果您有一个接口类型的指针指向实现多个接口的对象,您可能必须进行某种交叉转换以获得正确的类型,或者您可能必须引入一个表示继承的新抽象类来自所有不同的接口类型。接口类的多重继承也可能导致一些名称冲突,但如果接口设计正确,这通常不是问题。

      简而言之,出于编译器错误的原因,我强烈建议不要这样做,但如果您认为这是一个好的设计决策,那么一定要这样做。如今,编译器已经足够好,您很少(但不是从不)需要围绕它们构建您的设计。

      【讨论】:

        猜你喜欢
        • 2018-07-11
        • 2011-12-16
        • 1970-01-01
        • 1970-01-01
        • 2014-02-19
        • 2013-08-10
        • 2018-11-06
        • 2011-08-05
        • 1970-01-01
        相关资源
        最近更新 更多