¿Por qué son ilegales los métodos virtuales privados en C#?

Observo que hay dos preguntas aquí. En el futuro, podría considerar publicar dos preguntas en lugar de combinar dos preguntas en una. Cuando combinas preguntas como esta a menudo lo que sucede es que solo la primera recibe respuesta.

La primera pregunta es "¿por qué los métodos virtuales privados son ilegales en C#?"

Aquí están los argumentos contra la característica "métodos virtuales privados":

1. Private virtual solo es útil cuando tiene una clase derivada anidada. Este es un patrón útil, pero mucho menos común que la situación de clase derivada no anidada.

2. Si desea restringir la capacidad de sobreescribir el método en clases derivadas no anidadas, puede hacerlo restringiendo la capacidad de las clases no anidadas para derivar de la clase base; haga que todos los constructores de clases base sean privados. Por lo tanto, private virtual no es necesario para evitar la sobreescritura; protected virtual es suficiente, porque las únicas clases derivadas serán anidar.

3. Si desea restringir la capacidad de llamar a un método en una clase derivada no anidada, puede hacer que el método sea virtual interno y luego decirle a sus compañeros de trabajo que no usen ese método. Es irritante que el compilador no haga cumplir esto, pero el compilador tampoco hace cumplir ninguna otra restricción semántica sobre cómo se supone que debe usarse un método; obtener la semántica correcta es su negocio, no el del compilador, y tiene que hacer cumplir eso con revisiones apropiadas del código. Por lo tanto, private virtual no es necesario para evitar llamadas; las revisiones internas de código virtual plus son suficientes.

4. Es posible implementar este patrón ya con partes existentes:

   abstract class C
   {
       private int CF() { whatever; }
       private Func<int> f;
       public C() { f = CF; } 
       private int F() { return f(); }
       private class D : C
       {
           private int DF() { whatever; }
           public D() { f = DF; }
       }
   

   Ahora tengo un método F que es efectivamente virtual, pero solo puede ser "sobrescrito" por clases anidadas derivadas.

Dado que en todos los casos ya sea protegido, interno o interno protegido hace el truco, privado virtual es innecesario. Casi nunca es lo correcto, ya que tienes que estar ya comprometido a usar el patrón de clase derivado anidado. Entonces, el lenguaje lo hace ilegal.

Los argumentos para son:

Ha habido veces en código real en las que quiero que un método virtual sea un detalle de implementación privada de una clase que quiero que se extienda tanto por clases internas no anidadas como por clases internas anidadas. Tener que imponer el invariante para que el método interno no sea llamado por mis compañeros de trabajo son irritantes; me gustaría que el compilador lo hiciera cumplir sin tener que saltar a través de aros locos como hacer un campo de tipo delegado, etc.

También, está simplemente la cuestión de consistencia y ortogonalidad. Parece raro que dos cosas que deberían ser independientes accessibility accesibilidad y virtualidad have tengan un efecto en la otra innecesariamente.

Los argumentos en contra de la característica son bastante fuertes. Los argumentos a favor son bastante débiles. Por lo tanto, no hay tal función. Personalmente me gustaría mucho,pero entiendo totalmente por qué el equipo de diseño nunca me ha aceptado. No vale la pena el costo, y odiaría no enviar una mejor característica porque gastamos presupuesto en una característica que no beneficia a casi nadie.

La segunda pregunta es "¿Por qué en C# no es capaz de anular un método virtual privado en una clase derivada no anidada?"

Hay varias razones.

1. Porque solo puedes anular lo que puedo ver. Un método privado es un detalle de implementación privada de una clase base y no debe ser accesible.

2. Porque permitir eso tiene serias implicaciones de seguridad. Recuerde, en C++ casi siempre compila código en una aplicación a la vez. Tienes el código fuente para todo; todo es esencialmente "interno" desde la perspectiva de C++ la mayor parte del tiempo. En C#, ese no es el caso. Asambleas de terceros pueden obtener fácilmente en los tipos públicos de bibliotecas y producir nuevas extensiones a esas clases que luego se pueden utilizar sin problemas en lugar de instancias de la clase base. Dado que los métodos virtuales efectivamente cambian el comportamiento de una clase, cualquier código que dependa por razones de seguridad de invariantes de esa clase necesita ser cuidadosamente diseñado para que no dependan de invariantes garantizados por la clase base. Restringir la accesibilidad de los métodos virtuales ayuda a garantizar que los invariantes de esos métodos sean mantener.

3. Porque permitir eso proporciona otra forma del problema de la clase base frágil. C# ha sido cuidadosamente diseñado para ser menos susceptible al problema de la clase base frágil que otros lenguajes OO. Si un método virtual inaccesible se puede sobrescribir en una clase derivada, ese detalle de implementación privada de la clase base se convierte en un cambio de ruptura si se altera. Los proveedores de clases base deben ser libres de cambiar sus detalles internos sin preocuparse demasiado de que han roto las clases derivadas que dependen de ellos; idealmente, solo la interfaz pública documentada de un tipo debe mantenerse cuando cambian los detalles de la implementación.