Me sorprende que parezca haber tal consenso aquí de que no virtual por defecto es la forma correcta de hacer las cosas. Voy a caer en el otro lado, creo que pragmático, de la valla.
La mayoría de las justificaciones me parecen el viejo argumento de "Si te damos el poder, podrías lastimarte". ¿De los programadores?
Me parece que el codificador que no sabía lo suficiente (o no tenía suficiente tiempo) para diseñar su biblioteca para herencia y / o extensibilidad es el codificador que produjo exactamente la biblioteca que probablemente tenga que arreglar o modificar, exactamente el biblioteca donde la capacidad de anular sería más útil.
La cantidad de veces que tuve que escribir un código de solución feo y desesperado (o abandonar el uso y lanzar mi propia solución alternativa) porque no puedo anular mucho, supera con creces la cantidad de veces que me han mordido ( por ejemplo, en Java) anulando donde el diseñador podría no haber considerado que yo podría.
No virtual por defecto hace mi vida más difícil.
ACTUALIZACIÓN: Se ha señalado [bastante correctamente] que en realidad no respondí la pregunta. Entonces, y con disculpas por llegar bastante tarde ...
Quería un poco poder escribir algo conciso como "C # implementa métodos como no virtuales por defecto porque se tomó una mala decisión que valoraba los programas más que los programadores". (Creo que eso podría estar algo justificado en función de algunas de las otras respuestas a esta pregunta, como el rendimiento (optimización prematura, ¿alguien?), O garantizar el comportamiento de las clases).
Sin embargo, me doy cuenta de que solo estaría expresando mi opinión y no esa respuesta definitiva que desea Stack Overflow. Seguramente, pensé, en el nivel más alto, la respuesta definitiva (pero inútil) es:
No son virtuales de forma predeterminada porque los diseñadores del lenguaje tenían que tomar una decisión y eso es lo que eligieron.
Ahora supongo que la razón exacta por la que tomaron esa decisión nunca la vamos a ... ¡oh, espera! ¡La transcripción de una conversación!
Por lo tanto, parecería que las respuestas y comentarios aquí sobre los peligros de anular las API y la necesidad de diseñar explícitamente para la herencia están en el camino correcto, pero a todas les falta un aspecto temporal importante: la principal preocupación de Anders era mantener una clase o API implícita contrato entre versiones . Y creo que en realidad está más preocupado por permitir que la plataforma .Net / C # cambie bajo el código que por el cambio de código de usuario en la parte superior de la plataforma. (Y su punto de vista "pragmático" es exactamente lo opuesto al mío porque mira desde el otro lado).
(¿Pero no podrían simplemente haber elegido virtual por defecto y luego salpicado de "final" a través de la base de código? Quizás eso no sea lo mismo ... y Anders es claramente más inteligente que yo, así que lo dejaré mentir).
this
referencia es nula. Consulte aquí para obtener más información.