L'impostazione predefinita non predefinita ci porta all'ereditarietà della composizione?

Question

L'impostazione predefinita non predefinita ci porta all'ereditarietà della composizione?

#1 da (3 voti)
#2 da (2 voti)
#3 da (1 voti)

1

Ci sono alcune linee guida di progettazione sul codice verificabile in "The Art of Unit Testing". Il primo è "Rendi i metodi virtuali di default". Sono curioso di conoscere la tua idea sul comportamento non virtuale di default in C #. Ho letto delle opinioni di Hejlsberg, ma penso che uno dei motivi più importanti potrebbe essere che potrebbe portarci al principio di "composizione sull'ereditarietà".

È possibile che "la composizione sull'ereditarietà" sia uno di quei motivi che rendono preferibile non-virtuale-per-predefinito rispetto a quello virtuale-per-predefinito?

Aggiorna

Riguardo a questo argomento, considera il punto di vista guidato dal test; dove vogliamo scrivere codice testabile. Mentre siamo incoraggiati a rendere tutti i membri virtuali per impostazione predefinita (al libro menzionato), possiamo seguire "la composizione sull'ereditarietà" e continuare ad essere non-virtuali per impostazione predefinita. Non è meglio?

object-oriented unit-testing c# design-patterns inheritance

posta Amir Karimi 24.07.2013 - 08:41

fonte

3 risposte

Leggi altre domande sui tag object-oriented unit-testing c# design-patterns inheritance

quando prendersi gioco del test unitario [duplicato] se ho molte chiamate di un singolo metodo che restituisce il valore del campo, è meglio creare una variabile locale?

score 3 · Answer 1

Il virtuale esplicito è una forma di programmazione difensiva . Applicando i metodi che possono essere superati, ti assicuri che la persona che creerà una classe figlia non possa creare errori facendo qualcosa che non era inteso dalla progettazione del genitore.

Non penso che abbia nulla a che fare con il modo in cui le persone approcciano il design del loro codice dal punto di composizione rispetto all'eredità. Ma ci sono sicuramente persone che la ignoreranno sulla base del fatto che la programmazione difensiva non è una buona cosa.

score 2 · Answer 2

Penso che potrebbe, sì. Virtual per impostazione predefinita renderebbe molto più semplice sovrascrivere le implementazioni nelle classi ereditate.
Francamente, penso che sia una regola strana. Se hai davvero bisogno di scavalcare qualcosa, rendilo virtuale. Non rendere tutto virtuale solo perché alcune linee guida ti dicono di farlo.
Sembra roba che sentiresti al college (un consiglio generale che potrebbe morderti nel didietro quando applicato senza ripensamenti).

score 1 · Answer 3

Sono perplesso sul motivo per cui un libro sulla testabilità raccomanderebbe la creazione di metodi virtuali, a meno che non stia parlando più a un pubblico C ++ che a un pubblico C #.

Rendere i metodi virtuali dovrebbe essere fatto solo con grande cura e attenzione. La maggior parte delle classi che scrivo che non sono esplicitamente astratte sono generalmente sealed . In questo modo posso essere sicuro che il codice che scrivo è rhobust e accuratamente testato. Posso essere sicuro che nessun altro sviluppatore erediterà la mia classe, violerà il principio di sostituzione di Liskov e farà un qualche tipo di eccezione nel codice che ho scritto.

Se uno sviluppatore segue i principi SOLID, in particolare l'ultimo (inversione di dipendenza), la testabilità non dovrebbe rappresentare una preoccupazione enorme. È quando questi principi vengono violati che i test diventano molto più difficili.

Ecco le mie regole pratiche per scrivere un codice testabile:

Evita di scrivere metodi / classi statici.
Segui i principi SOLID.
sigilla il maggior numero di classi possibile e usa la parola chiave virtual con parsimonia.

Con gli strumenti di analisi delle dipendenze e di simulazione, i test sono facili da scrivere (anche se alcuni diventano lunghi a causa dei dati necessari per testarli).