是否应该将实现接口类的纯虚方法的方法声明为虚拟?

tyr*_*dis 7 c++ methods virtual interface

我读到了关于这个问题的不同意见.假设我有一个带有一堆纯虚方法的接口类.我在实现接口的类中实现这些方法,我不希望从实现派生.

是否需要将实现中的方法声明为虚拟?如果是,为什么?

BЈо*_*вић 9

否 - 在基类中声明为virtual的每个函数方法在所有派生类中都是虚拟的.

但良好的编码实践告诉我们将这些方法声明为虚拟.


Kir*_*rov 7

真正的需要 - 没有.一旦方法在基类中声明为虚拟,它就会为所有派生类保持虚拟.但是知道哪个方法是虚拟的以及哪个方法是好的 - 而不是在基类中检查它.此外,在大多数情况下,您无法确定是否会导出您的代码(例如,如果您正在为某个公司开发某些软件).正如我所说,这不是问题,因为一旦声明为虚拟,它会保持虚拟,但以防万一..(:


Ste*_*end 7

virtual 在派生类覆盖声明中是可选的,但为了清楚起见,我个人包括它.


vit*_*aut 6

不,virtual不需要,并且它不能防止任何开发人员错误,尽管许多开发人员更喜欢添加它。

从 C++11 开始,您可以使用overrideorfinal说明符来代替。


Chr*_*cke 5

没有要求将它们标记为虚拟.

我首先讨论虚拟广告向读者宣传派生类覆盖虚拟做一些有用的事情.如果要实现虚拟操作,那么虚拟方法可能与您的类的类型无关:在这种情况下将虚拟标记为虚拟.考虑:

class CommsObject {
   virtual OnConnect();
   virtual OnRawBytesIn();
};

class XMLStream : public CommsObject {
    virtual OnConnect();
            OnRawBytesIn();
    virtual OnXMLData();
};
Run Code Online (Sandbox Code Playgroud)

在该示例中,OnConnect在两个类中都被记录为虚拟,因为后代总是想知道它是有意义的.OnRawBytesIn对XMLStream中的"Export"没有意义,因为它使用它来处理原始字节,并生成解析数据 - 它通过OnXMLData()进行通知.

完成所有这些后,我认为第三类的维护者,看着XMLStream,可能会认为创建自己的OnRawBytes函数并期望它作为正常的重载函数工作是"安全的" - 即基类会调用内部正确的,而外部类会掩盖内部的OnRawBytes.

因此,省略虚拟隐藏了类的消费者的重要细节,并使代码以意想不到的方式运行.

所以我已经完全循环:不要试图用它来暗示函数的预期用途 - 将它用作函数行为的暗示:标记函数虚拟一致,以便下游程序员必须读取较少的文件知道函数在被覆盖时的行为方式.