Sollen Methoden, die reine virtuelle Methoden einer Interface-Klasse implementieren, auch als virtuell deklariert werden?

Question

Ich habe verschiedene Meinungen über diese 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?

Answer 1

Nein - jede Funktion Methode deklariert in der Basisklasse virtuell in allen abgeleiteten Klassen virtuell sein

Aber gute Programmierpraktiken sagen virtuellen diese Methoden zu erklären

Answer 2

Echte Notwendigkeit - 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 ich schon sagte, es ist kein Problem, da einmal als virtuelle erklärt, es bleibt virtuell, aber nur für den Fall .. (:.

Answer 3

Wenn Sie noch nie von einer Klasse ableiten, dann gibt es keinen Sinn macht seine Methoden virtuellen

Answer 4

virtual in der abgeleiteten Klasse überschreiben Deklaration ist optional.. , aber aus Gründen der Klarheit schließe ich es persönlich ein.

Answer 5

Sie müssen nicht virtuell markiert werden.

Ich würde damit anfangen zu argumentieren, dass virtuelle Werbung für Leser, die Sie erwarten, dass abgeleitete Klassen die virtuelle überschreiben, 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. betrachten:

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

class XMLStream : public CommsObject { 
    virtual OnConnect(); 
      OnRawBytesIn(); 
    virtual OnXMLData(); 
}; 

In diesem Beispiel wird OnConnect als virtuelle in beiden Klassen dokumentiert, weil es Sinn macht, dass ein Nachkomme würde immer wissen will. OnRawBytesIn ist nicht sinnvoll, um aus XMLStream zu "exportieren", da es Rohdaten verarbeitet und geparste Daten generiert, die es über OnXMLData() benachrichtigt.

Nachdem ich das alles getan habe, würde ich dann argumentieren, dass der Betreuer einer dritten Klasse, XMLStream betrachtend, denken könnte, dass es "sicher" wäre, ihre eigene OnRawBytes-Funktion zu erstellen und zu erwarten, dass sie normal überlastet funktioniert Funktion - dh die Basisklasse würde die interne richtige aufrufen, und die äußere würde die internen OnRawBytes maskieren.

Das Auslassen des virtuellen Systems hat daher wichtige Details von den Benutzern der Klasse verborgen und den Code auf unerwartete Weise verändert.

So ist der Kreis voll: Versuchen Sie nicht, ihn als Hinweis auf den Verwendungszweck einer Funktion zu verwenden - verwenden Sie ihn als Hinweis auf das Verhalten der Funktion: Markieren Sie Funktionen virtuell konsistent, also nachgeschaltete Programmierer Lesen Sie weniger Dateien, um zu wissen, wie sich eine Funktion beim Überschreiben verhält.

Answer 6

Nein, es wird nicht benötigt und es verhindert keine Codierungsfehler, obwohl viele Programmierer es bevorzugen.

Sobald C++ 0x Mainstream wird, können Sie stattdessen den override Specifier verwenden.

Answer 7

Einmal 'virtuell', ist es virtuell bis zum letzten Kind.Afaik, das ist das Merkmal von C++.