Ho letto opinioni diverse su questa domanda. Diciamo che ho una classe di interfaccia con una serie di metodi virtuali puri. Implemento questi metodi in una classe che implementa l'interfaccia e non mi aspetto di derivare dall'implementazione.I metodi che implementano metodi virtuali puri di una classe di interfaccia devono essere dichiarati anche virtuali?
Esiste la necessità di dichiarare i metodi nell'implementazione altrettanto virtuali? Se sì, perché?
No - ogni metodo funzione dichiarata virtuale nella classe base sarà virtuale in tutte le classi derivate
Ma le buone pratiche di codifica stanno dicendo di dichiarare quei metodi virtuali
Vero bisogno - no. Una volta che un metodo è dichiarato come virtuale nella classe base, rimane virtuale per tutte le classi derivate. Ma è bene sapere quale metodo è virtuale e quale no, invece di verificarlo nella classe base. Inoltre, nella maggior parte dei casi, non puoi essere sicuro, se il tuo codice sarà derivato o meno (ad esempio, se stai sviluppando software per alcune aziende). Come ho già detto, non è un problema, dato che una volta dichiarato come virtuale, rimane virtuale, ma nel caso .. (:
Se non si deriva da una classe, non ha senso rendere i suoi metodi virtuali
virtual è facoltativo nella dichiarazione della classe di override derivata.. , ma per chiarezza lo includo personalmente.
Non è necessario contrassegnarli come virtuali.
Inizierei sostenendo che la pubblicità virtuale ai lettori prevede che le classi derivate ignorino il virtuale per fare qualcosa di utile. Se stai implementando il virtual per fare qualcosa, allora il metodo virtuale potrebbe non avere nulla a che fare con il tipo di cosa che è la tua classe: nel qual caso contrassegnarlo virtuale è sciocco. prendere in considerazione:
class CommsObject {
virtual OnConnect();
virtual OnRawBytesIn();
};
class XMLStream : public CommsObject {
virtual OnConnect();
OnRawBytesIn();
virtual OnXMLData();
};
In questo esempio, OnConnect è documentato come virtuale in entrambe le classi, perché ha senso che un discendente sarebbe sempre vogliono sapere. OnRawBytesIn non ha senso "Esportare" da XMLStream poiché lo utilizza per gestire i byte non elaborati e generare dati analizzati, che vengono notificati tramite OnXMLData().
Dopo aver fatto tutto questo, avrei allora sostengo che il manutentore di un 3 ° di classe, guardando XMLStream, potrebbe pensare che sarebbe stato "sicuro" per creare la propria funzione OnRawBytes e si aspettano di lavorare come un normale sovraccarico funzione - cioè la classe base chiamerebbe quella corretta interna e quella esterna maschererebbe gli OnRawByte interni.
Così omettere il virtuale ha nascosto dettagli importanti ai consumatori della classe e ha comportato il codice in modo inaspettato.
Così Ive andato cerchio completo: Non cercare di usarlo come un suggerimento in merito alla destinazione di una funzione - ne fanno uso come un suggerimento circa il comportamento della funzione: Funzioni marchio virtuali programmatori costantemente così a valle devono lettura meno file di sapere come una funzione si comporterà quando ignorato.
No, non è necessario e non impedisce eventuali errori di codifica, anche se molti programmatori preferiscono metterlo.
Una volta che C++ 0x diventa corrente principale sarete in grado di utilizzare il override specificatore invece.
Una volta 'virtuale', è virtuale tutta la strada fino a l'ultimo figlio.Afaik, questa è la caratteristica del C++.
A meno che non venga utilizzato come parte di una libreria. –