Ich habe verschiedene Meinungen zu dieser Frage gelesen. Nehmen wir an, ich habe eine Interface-Klasse mit einer Reihe rein virtueller Methoden. Ich implementiere diese Methoden in einer Klasse, die die Schnittstelle implementiert und ich erwarte nicht, dass sie von der Implementierung abgeleitet wird.
Müssen die Methoden in der Implementierung auch als virtuell deklariert werden? Wenn ja, warum?
virtual
ist optional in der Deklaration der abgeleiteten Klassenüberschreibung, aber aus Gründen der Klarheit schließe ich es persönlich ein.
Wirkliches Bedürfnis - nein. Sobald eine Methode in der Basisklasse als virtuell deklariert ist, bleibt sie für alle abgeleiteten Klassen virtuell. Aber es ist gut zu wissen, welche Methode virtuell ist und welche - statt dies in der Basisklasse zu überprüfen. Außerdem können Sie in den meisten Fällen nicht sicher sein, ob Ihr Code abgeleitet wird oder nicht (z. B. wenn Sie eine Software für ein Unternehmen entwickeln). Wie gesagt, es ist kein Problem, wie es einmal als virtuell deklariert wurde, es bleibt virtuell, aber nur für den Fall .. (:
Es ist nicht erforderlich, sie als virtuell zu markieren.
Ich würde damit anfangen, zu argumentieren, dass virtuelle Werbung für Leser bedeutet, dass Sie erwarten, dass abgeleitete Klassen das Virtuelle außer Kraft setzen, um etwas Nützliches zu tun. Wenn Sie das Virtuelle implementieren, um etwas zu tun, dann hat die virtuelle Methode vielleicht nichts damit zu tun, was Ihre Klasse ist: In diesem Fall ist es albern, sie zu markieren. beachte:
%Vor%In diesem Beispiel ist OnConnect in beiden Klassen als virtuell dokumentiert, da es sinnvoll ist, dass ein Abkömmling immer wissen möchte. OnRawBytesIn ist nicht sinnvoll, um aus XMLStream zu "exportieren", da es verwendet wird, um rohe Bytes zu verarbeiten, und um analysierte Daten zu generieren, die es über OnXMLData () benachrichtigt.
Wenn ich all das getan habe, würde ich argumentieren, dass der Betreuer einer dritten Klasse, der sich XMLStream ansieht, denken könnte, dass es "sicher" wäre, seine eigene OnRawBytes-Funktion zu erstellen und zu erwarten, dass sie als normale überladene Funktion funktioniert - dh die Basisklasse würde die interne korrekte Adresse aufrufen, und die äußere würde die internen OnRawBytes maskieren.
Das Auslassen des virtuellen Systems hat also wichtige Details der Benutzer der Klasse verborgen und den Code auf unerwartete Weise verändert.
So ist der Kreis geschlossen: Versuchen Sie nicht, ihn als Hinweis auf den beabsichtigten Zweck einer Funktion zu verwenden - benutzen Sie ihn als Hinweis auf das Verhalten der Funktion: Markieren Sie Funktionen virtuell konsistent, so dass nachfolgende Programmierer lesen müssen weniger Dateien, um zu wissen, wie sich eine Funktion beim Überschreiben verhält.
Sobald es "virtuell" ist, ist es virtuell bis zum letzten Kind. Afaik, das ist das Merkmal von C ++.
Wenn Sie niemals von einer Klasse ableiten, macht es keinen Sinn, ihre Methoden virtuell zu machen.