¿Debería una propiedad protegida en una clase secundaria C# ocultar el acceso a una propiedad pública en el elemento primario?

Question

tengo el siguiente código:

public class Parent 
{ 
    public string MyField { get; set; } 
} 

public class Child : Parent 
{ 
    protected new int MyField { get; set; } 
} 

Trato de acceder a este con:

static void Main(string[] args) 
{ 
    Child child = new Child(); 
    child.MyField = "something"; 
} 

Visual Studio 2008 compila esto sin comentario, pero bajo Mono (2.4.2, Ubuntu) consigo el mensaje de error

'HideTest.Child.MyField' is inaccessible due to its protection level (CS0122) 

¿Hay una implementación u otra que cumpla más con el estándar aquí?

Edit: Gracias a todas las personas que han señalado el mal diseño. Lamentablemente, es una biblioteca de terceros y cambiarla significativamente no es práctico.

Answer 1

De ECMA-334 (la especificación C#) §10.7.1.2:

A declaration of a new member hides an inherited member only within the scope of the new member.

se puede ver este comportamiento mediante la ejecución de esta prueba en la implementación de Microsoft.

using System; 
using NUnit.Framework; 

namespace ScratchPad 
{ 
    [TestFixture] 
    public class Class1 
    { 
     [Test] 
     public void InheritanceHiding() 
     { 
      var b = new Base(); 
      var d = new Derived(); 

      var baseSomeProperty = b.SomeProperty; 
      var derivedSomeProperty = d.SomeProperty; 

      b.GetSomeProperty(); 
      d.GetSomeProperty(); 
     } 
    } 

    public class Base 
    { 
     public string SomeProperty 
     { 
      get 
      { 
       Console.WriteLine("Getting Base.SomeProperty"); 
       return "Base.SomeProperty"; 
      } 
     } 

     public string GetSomeProperty() 
     { 
      return SomeProperty; 
     } 
    } 

    public class Derived : Base 
    { 
     protected new int SomeProperty 
     { 
      get 
      { 
       Console.WriteLine("Getting Derived.SomeProperty"); 
       return 3; //Determined by random roll of the dice. 
      } 
     } 

     public new int GetSomeProperty() 
     { 
      return SomeProperty; 
     } 
    } 
} 

Cuál sería:

Getting Base.SomeProperty //(No Controversy) 
Getting Base.SomeProperty //(Because you're calling from public scope and the new member is in protected scope, there is no hiding) 
Getting Base.SomeProperty //(No Controversy) 
Getting Derived.SomeProperty //(Now because you're calling from protected scope, you get the protected member). 

Así que la propiedad que usted está accediendo desde su Main() debe ser la característica de la clase base (como lo es en MS.NET), no la propiedad derivada (como se en Mono), porque el nuevo miembro derivado solo oculta el 'antiguo' miembro base en el alcance protegido.

Mono está haciendo algo mal aquí de acuerdo con la especificación.

Answer 2

mi humilde opinión, la diferencia es que MS.NET reconoce el tipo cadena de MyField y establece el valor de la propiedad y en Parent Mono en tan sólo intenta acceder MyFieldChild en clase.

Answer 3

Está haciendo que algo disponible a través de la clase base no esté disponible a través del niño. Puedes intentarlo, pero en realidad no hará nada. La gente siempre puede hacer esto:

Parent child = new Child();

y llama al método. Entonces, si desea que el campo esté oculto, declare uno nuevo y mantenga el público heredado.

Answer 4

En general, la implementación .NET de C# probablemente debería considerarse "canon". A partir de la documentación sobre el new Modifier:

A constant, field, property, or type introduced in a class or struct hides all base class members with the same name.

... parece que la aplicación Mono es más correcto dada esta definición. Debería estar ocultando la implementación de MyField en la clase Parent y, por lo tanto, solo debería poder accederse con la firma int MyField de la clase Child.

Answer 5

Preludio: Este código es una locura. Si realmente tienes un código en tu aplicación como este, arréglelo ahora. ¡O haz que ambos estén protegidos o sean públicos!

En cuanto al error: El CLR tiene muchas reglas realmente extrañas de "borde del caso" para tratar con cosas como esta. El mejor lugar para buscar este tipo de cosas suele ser Eric Lippert's blog.

Al decir que, sin embargo, parece que mono realmente está haciendo lo más sensato aquí en mi opinión.

---

En segundo lugar, el C# tiene más sentido una vez que se toma en cuenta lo de "detrás de escena".

Las propiedades no son de "primera clase" en MSIL. Una propiedad en C# o VB simplemente se compila en un método get y set (el compilador también pega un atributo en algún lugar para la contabilidad).

int MyField { get; set; } producirá realmente MSIL por dos métodos:

void set_MyField(int value); 
int get_MyField(); 

Ahora, dado que su método new tiene un tipo diferente, que va a terminar con los siguientes 2 métodos setter.

void set_MyField(int value); 
void set_MyField(string value); 

Cuando se llama a x.MyField = "string" Estás a llamar a uno de esos métodos. Esto se reduce a un escenario de sobrecarga de método normal. Es perfectamente válido tener dos métodos con el mismo nombre que tomen diferentes parámetros, por lo que el compilador simplemente seleccionará la cadena uno y continuará de manera feliz.

Así que sí. El C# uno tiene sentido si sabes cómo funcionan las partes internas, el Mono tiene más sentido si no lo haces.

¿Cuál es "más correcto"? Pedir a Eric Lippert :-)

Answer 6

La respuesta de Jason es correcta, pero él pide una justificación de este comportamiento. (A saber, que un método de ocultación solo se oculta dentro del alcance del método de ocultación).

Existen varias justificaciones posibles. Uno en particular es ese this is yet another way in which the design of C# mitigates the Brittle Base Class problem.

FooCorp hace Foo.dll:

public class Foo 
{ 
    public object Blah() { ... } 
} 

BarCorp hace bar.dll:

public class Bar : Foo 
{ 
    // stuff not having to do with Blah 
} 

ABCCorp hace abc.exe:

public class ABC 
{ 
    static void Main() 
    { 
     Console.WriteLine((new Bar()).Blah()); 
    } 
} 

Ahora BarCorp dice "Usted sabe, en nuestro código interno podemos garantizar que Blah solo devuelve cadena gracias a nuestro conocimiento de nuestra implementación derivada. Vamos a tomar e ventaja de ese hecho en nuestro código interno ".

public class Bar : Foo 
{ 
    internal new string Blah() 
    { 
     object r = base.Blah(); 
     Debug.Assert(r is string); 
     return (string)r; 
    } 
} 

ABCCorp recoge una nueva versión de bar.dll que tiene un montón de correcciones de errores que les están bloqueando. ¿Debería romper su compilación porque tienen una llamada a Blah, un método interno en la barra? Por supuesto no. Eso sería terrible.Este cambio es un detalle de implementación privada que debe ser invisible fuera de Bar.DLL.

Answer 7

Simplemente agregando mis 2 centavos) Eso es un error Mono, here es la descripción.