anulando la protección interna con protegido!

Question

Esto es extension para este question pedido hace una hora.

No podemos modificar el access modifiers, al anular un virtual method en la clase . Considere Control clase en System.Web.UI espacio de nombres

public class Control : IComponent, IDisposable,... 
{ 
    protected internal virtual void CreateChildControls() 
    { } 
    . 
    . 
} 

ahora esto

public class someClass : System.Web.UI.Control 
    { 
     // This should not compile but it does 
     protected override void CreateChildControls() 
     { } 

     // This should compile but it does not 
     protected internal override void CreateChildControls() 
     { } 
    } 

cualquier organismo puede explicar esto? Gracias

Answer 1

No podemos modificar los modificadores de acceso al anular un método virtual en la clase derivada.

Esa afirmación es falsa. Puede y debe cambiar los modificadores de acceso cuando se encuentre exactamente en la situación que describe. En otras situaciones, no debe cambiar los modificadores de acceso.

remito a la sección 10.6.4 de la especificación, que establece:

una declaración de anulación no puede cambiar la accesibilidad del método virtual . Sin embargo, si el método de base anulado está protegido interna y se declara en un conjunto diferente que el ensamblaje que contiene el método override entonces del método de reemplazo declaró accesibilidad debe ser protegida.

El razonamiento es sencillo.

Usted, Asad, tiene una cuenta bancaria, Cuenta bancaria.

Tienes una casa. Usted alquila una habitación en House a su mejor amigo Charlie.

Charlie tiene un hijo, David, que vive en un apartamento.

Tienes un hijo, Elroy, que vive en un condominio.

Elroy tiene un hijo, su nieto, Frank, que vive en una yurta.

Elroy tiene un mejor amigo Greg que vive en el condominio con él.

Usted otorga acceso a su Cuenta Bancaria a usted, a cualquier persona que viva en la Casa ya cualquiera de sus descendientes. Entonces las personas que pueden acceder a la cuenta bancaria son Asad, Charlie, Elroy y Frank.

David no tiene acceso porque no es ni usted ni su descendiente, ni está viviendo en la casa. Que él es un hijo de tu compañero de casa es irrelevante; él no tiene acceso a su Cuenta bancaria.

Greg tampoco tiene acceso a su cuenta bancaria. Él no es tu descendiente. Él no vive en House. El hecho de que esté viviendo con su descendiente no le otorga los mismos derechos que su descendiente.

Ahora llegamos al quid de la cuestión. Elroy no tiene permiso para extender el acceso a su cuenta bancaria a Greg. Eres el propietario de esa Cuenta bancaria, y dijiste "yo mismo, mis descendientes y mis compañeros de casa". Sus hijos no tienen derecho a extender el acceso de BankAccount más allá de lo que inicialmente configuró.

Cuando Elroy describe qué acceso tiene a BankAccount, solo puede decir "concedo acceso a esto a mí y a mis descendientes", porque eso es lo que ya permitiste. No puede decir "concedo acceso a BankAccount para mí, mis descendientes y para los demás residentes de Condo".

Para que quede claro:

• I y mis descendientes obtener acceso = acceso protegido
• yo y mis compañeros de casa consigo el acceso = acceso interno
• I y mis descendientes y mis compañeros de casa obtener acceso = protegido de acceso interno
• control = Asad
• CreateChildControls = CuentaBancaria
• Casa System.web.dll =
• Charlie = cualquier tipo en System.web.dll
• David = tipo derivado de Charlie en el montaje Apartment.DLL
• Elroy = algunaClase
• Condo = su conjunto que contiene SomeClass
• Greg = alguna otra clase en Condo.DLL
• Frank = tipo derivado de algunaClase en Yurt.DLL
• Yurt = algún otro conjunto de

Answer 2

Porque, si bien la terminología es diferente, anularla como protected mantiene la visibilidad del miembro de la misma. Si se le permitiera anularlo como protected internal, de repente expondría el miembro a cualquier otro tipo en su conjunto.

Answer 3

Protegido interno significa protegido O interno. De modo que si anulando fuera del ensamblaje original se le permitía marcarlo como interno, estaría permitiendo que otras clases en el mismo ensamblaje que el overrider llamaran a este método. Eso significaría efectivamente que se violaría la encapsulación interna del padre original.