大型抽象基类

Question

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

在实现类的基类中查找要实现的所有函数有点单调乏味，主要是因为MSVC ++没有告诉你你用编译器错误实现了哪个函数“无法构造抽象类“

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

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

Answer 1

我认为接口类本质上是坏的，但是提出的问题使得这个特定的应用程序听起来很可疑。

如果你有从这个界面派生的类，并且不清楚你需要覆盖哪些函数，那似乎表明所有这些函数可能都没有必要。

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

Answer 2

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

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

简而言之，我强烈建议不要因编译错误原因而这样做，但如果你认为这是一个很好的设计决定，那么一定要去做。编程器现在已经足够好了，你很少（但不是永远）不需要围绕它们构建你的设计。

Answer 3

无论如何，这样一个大班是一团糟，上帝级反。使用聚合/组合分割一个类并看看SOLID开发原则，看起来像单个类的30个方法不遵循单一责任原则，至少...所以我想建议重新考虑一个类的设计。祝你好运！

Answer 4

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