Je suis surpris qu'il semble y avoir un tel consensus ici que le non-virtuel par défaut est la bonne façon de faire les choses. Je vais descendre de l'autre côté - je pense pragmatique - de la clôture.
La plupart des justifications me lisent comme le vieil argument «Si nous vous donnons le pouvoir, vous pourriez vous blesser». Des programmeurs?!
Il me semble que le codeur qui ne savait pas assez (ou qui n'avait pas assez de temps) pour concevoir sa bibliothèque pour l'héritage et / ou l'extensibilité est le codeur qui a produit exactement la bibliothèque que je devrai probablement corriger ou modifier - exactement le bibliothèque où la possibilité de remplacer serait la plus utile.
Le nombre de fois où j'ai eu à écrire du code de contournement laid et désespéré (ou à abandonner l'utilisation et à lancer ma propre solution alternative) parce que je ne peux pas passer outre, dépasse de loin le nombre de fois où j'ai été mordu ( par exemple en Java) en remplaçant là où le concepteur n'aurait peut-être pas pensé que je pourrais.
Le non-virtuel par défaut me rend la vie plus difficile.
MISE À JOUR: Il a été souligné [tout à fait correctement] que je n'ai pas vraiment répondu à la question. Donc - et avec des excuses pour être plutôt en retard ...
Je voulais en quelque sorte être capable d'écrire quelque chose de concis comme "C # implémente des méthodes comme non virtuelles par défaut parce qu'une mauvaise décision a été prise qui valorisait plus les programmes que les programmeurs". (Je pense que cela pourrait être quelque peu justifié sur la base de certaines des autres réponses à cette question - comme la performance (optimisation prématurée, n'importe qui?), Ou la garantie du comportement des classes.)
Cependant, je me rends compte que je ne ferais que donner mon opinion et non la réponse définitive que Stack Overflow souhaite. Sûrement, j'ai pensé, au plus haut niveau, la réponse définitive (mais inutile) est:
Ils ne sont pas virtuels par défaut car les concepteurs de langage avaient une décision à prendre et c'est ce qu'ils ont choisi.
Maintenant, je suppose que la raison exacte pour laquelle ils ont pris cette décision, nous ne ... oh, attendez! La transcription d'une conversation!
Il semblerait donc que les réponses et les commentaires ici sur les dangers de la substitution des API et la nécessité de concevoir explicitement pour l'héritage sont sur la bonne voie, mais manquent tous un aspect temporel important: la principale préoccupation d'Anders était de maintenir implicite une classe ou une API. contrat entre les versions . Et je pense qu'il est en fait plus préoccupé par le fait de permettre à la plate-forme .Net / C # de changer sous le code plutôt que par le changement du code utilisateur au-dessus de la plate-forme. (Et son point de vue «pragmatique» est l'exact opposé du mien parce qu'il regarde de l'autre côté.)
(Mais ne pourraient-ils pas simplement avoir choisi virtuel par défaut, puis "final" parsemé de la base de code? Peut-être que ce n'est pas tout à fait la même chose ... et Anders est clairement plus intelligent que moi, alors je vais laisser tomber.)
this
référence est nulle. Voir ici pour plus d'informations.