¿Los métodos que implementan métodos virtuales puros de una clase de interfaz deben declararse también virtuales?

Question

He leído diferentes opiniones sobre esta pregunta. Digamos que tengo una clase de interfaz con un montón de métodos virtuales puros. Implemento esos métodos en una clase que implementa la interfaz y no espero derivar de la implementación.

¿Existe una necesidad de declarar los métodos en la implementación como virtuales también? ¿Si es así por qué?

Answer 1

No - cada método de la función declarada virtual en la clase base será virtual en todas las clases derivadas

Pero buenas prácticas de codificación están diciendo que declarar esos métodos virtuales

Answer 2

Necesidad real - no. Una vez que un método se declara como virtual en la clase base, se mantiene virtual para todas las clases derivadas. Pero es bueno saber qué método es virtual y cuál no, en lugar de verificar esto en la clase base. Además, en la mayoría de los casos, no puede estar seguro si su código será derivado o no (por ejemplo, si está desarrollando algún software para alguna empresa). Como dije, no es un problema, ya que una vez declarado como virtual, permanece virtual, pero por si acaso ... (:

Answer 3

Si nunca deriva de una clase, no tiene sentido hacer que sus métodos sean virtuales.

Answer 4

virtual es opcional en la declaración de anulación clase derivada.. , pero para mayor claridad lo incluyo personalmente.

Answer 5

No es necesario marcarlos como virtuales.

Comenzaría argumentando que los anunciantes virtuales a los lectores esperan que las clases derivadas anulen las virtuales para hacer algo útil. Si está implementando lo virtual para hacer algo, entonces el método virtual podría no tener nada que ver con el tipo de cosa que es su clase: en cuyo caso, marcarlo virtual es una tontería. tener en cuenta:

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

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

En ese ejemplo, OnConnect se documenta como virtual en ambas clases porque tiene sentido que un descendiente siempre querría saber. OnRawBytesIn no tiene sentido para "Exportar" desde XMLStream, ya que usa eso para manejar bytes sin formato, y generar datos analizados, que notifica a través de OnXMLData().

Habiendo hecho todo eso, entonces argumentaría que el mantenedor de una tercera clase, mirando XMLStream, podría pensar que sería "seguro" crear su propia función OnRawBytes y esperar que funcione como una sobrecarga normal función - es decir, la clase base llamaría a la correcta interna, y la externa enmascararía los OnRawBytes internos.

omitiendo lo virtual ha ocultado detalles importantes de los consumidores de la clase e hizo que el código se comporte de forma inesperada.

Ha terminado el ciclo completo: no intente utilizarlo como una pista sobre el propósito de una función. HÁGALO como una pista sobre el funcionamiento de la función: marque las funciones virtuales de forma consistente para que los programadores posteriores tengan que lea menos archivos para saber cómo se comportará una función cuando se invalide.

Answer 6

No, no es necesario y no evita errores de codificación, aunque muchos codificadores prefieren ponerlo.

Una vez que C++ 0x se convierta en convencional, en su lugar podrá utilizar el especificador override.

Answer 7

Una vez que 'virtual', es virtual hasta el último hijo.Afaik, esa es la característica de C++.