proteccion - protected c# español

Anulando protegido interno con protegido!

Question

Esta es una extension para esta question hecha hace una hora.

No podemos modificar los modificadores de access modifiers al anular un virtual method en una clase derived . Considere Control clase de Control en el espacio de nombres System.Web.UI

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

Ahora considera 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()
        { }  
    }

¿Puede alguien explicar esto? Gracias

Answer 1

No podemos modificar los modificadores de acceso cuando se reemplaza un método virtual en una clase derivada.

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

Lo 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 base anulado está protegido internamente y se declara en un ensamblaje diferente al ensamblado que contiene el método de anulación, entonces se debe proteger la accesibilidad declarada del método de anulación.

El razonamiento es sencillo.

Tú, Asad, tienes una cuenta bancaria, BankAccount.

Tienes una casa. Alquila una habitación en casa a tu 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, tu nieto, Frank, que vive en una Yurt.

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

Usted otorga acceso a su cuenta bancaria a usted mismo, a cualquier persona que viva en House y a cualquiera de sus descendientes. Así que las personas que pueden acceder a la cuenta bancaria son Asad, Charlie, Elroy y Frank.

David no tiene acceso porque él no es ni tú, ni tu 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 casa. El hecho de que él esté viviendo con tu descendiente no le otorga los mismos derechos que tu descendiente.

Ahora llegamos al punto crucial del asunto. Elroy no tiene permiso para extender el acceso a su cuenta bancaria a Greg. Usted es dueño de esa cuenta bancaria, y dijo "yo, mis descendientes y mis compañeros de casa". Sus hijos no tienen derecho a extender la accesibilidad de BankAccount más allá de lo que usted configuró inicialmente.

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

Para ser claro:

• Yo y mis descendientes tenemos acceso = acceso protegido
• Yo y mis compañeros tenemos acceso = acceso interno
• Yo, mis descendientes y mis compañeros de casa tienen acceso = acceso interno protegido
• Control = Asad
• CreateChildControls = BankAccount
• House = System.Web.DLL
• Charlie = cualquier tipo en System.Web.DLL
• David = tipo derivado de Charlie en ensamblaje Apartment.DLL
• Elroy = someClass
• Condo = su montaje que contiene SomeClass
• Greg = alguna otra clase en Condo.DLL
• Frank = tipo derivado de someClass en Yurt.DLL
• Yurta = alguna otra asamblea

Answer 2

Porque, si bien la terminología es diferente, anularla como protected mantiene la visibilidad del miembro igual. Si se le permitiera anularlo como protected internal , entonces de repente estaría exponiendo al miembro a cualquier otro tipo en su ensamblaje.

Answer 3

Protegido interno significa protegido O interno. Por lo tanto, si al reemplazar fuera del ensamblaje original se le permitió marcarlo como protegido interno, se permitiría que otras clases en el mismo ensamblaje que el sobrepuesto llamen a este método. Eso significaría efectivamente que la encapsulación interna del padre original sería violada.