c# - niveles - ¿Por qué la protección interna no es más restrictiva que interna?

protected internal c#

Question

Me gustaría crear una auto-propiedad interna:

internal bool IP { get; protected internal set; }

Pensé que sería posible hacer que el configurador esté protected o protected internal , pero siempre el modificador de accesibilidad de error debe ser más restrictivo que la propiedad . ¿No es ese el caso? Private no me ayuda, aquí.

EDITAR:
La pregunta es: ¿cómo implemento una auto-propiedad con un getter interno y un setter protegido?

Answer 1

el modificador de accesibilidad debe ser más restrictivo que la propiedad

Interna es más restrictiva que protegida: porque se pueden ver cosas protegidas (por subclases) fuera del ensamblaje.

El compilador dice que no tiene sentido decir que el set está protegido (es decir, visible para las subclases fuera del ensamblaje), cuando toda IP propiedad IP es interna (es decir, invisible fuera del ensamblaje).

Answer 2

Consideraría esta trampa, ya que Eric Lippert está en SO, pero escribió una excelente publicación en el blog que considera este problema.

¿Por qué no puedo acceder a un miembro protegido de una clase derivada, tercera parte?

En última instancia, su respuesta es en gran medida la misma que la de los carteles que figuran aquí, pero publica algunos razonamientos interesantes detrás del diseño del lenguaje y la implementación de estas características.

Answer 3

En el nivel .NET, hay dos niveles de acceso similares pero distintos:

• FamilyAndAssembly: más restrictivo que el protegido o interno
• FamilyOrAssembly: menos restrictivo que el protegido o interno

"interno protegido" en C # significa FamilyOrAssembly; no hay ningún modificador para FamilyAndAssembly.

Por lo tanto, su protected internal es menos restrictivo que la propiedad general internal . Lo que podrías hacer es:

protected internal bool IP { internal get; set; }

Pero entonces tu setter es menos restringido que tu getter, lo cual es extraño ...

Otra alternativa (algo equivalente) es:

internal bool IP { get; set; }
protected void SetIP(bool ip)
{
this.IP = ip;
}

Answer 4

Está efectivamente protected o internal , no y . Es accesible tanto por clases derivadas como por tipos en el mismo ensamblaje. Es un error común pensar que protected internal medios protected internal accesibles solo para las clases derivadas en el mismo conjunto.

Answer 5

Teniendo en cuenta lo que Jon Skeet mencionó (y el comentario de user59808), ¿no lograría esto el resultado deseado?

protected internal bool IP { get; protected set; }

Answer 6

medios internos protegidos protegidos O internos, no protegidos e internos. Entonces, el alcance está limitado a la misma asamblea O clases derivadas, no necesariamente ambas.

Answer 7

medios internos protegidos visibles para las clases en el mismo conjunto, o para las clases derivadas de la clase contenedora; en otras palabras, es visible para aquellos que cumplen los requisitos internos O los requisitos protegidos, no AND. No hay un modificador de acceso que signifique protegido Y interno de esta manera.

Answer 8

protected internal es menos restrictivo que protected o internal porque permite que sus subclases ( protected ) y cualquier cosa en el mismo conjunto ( internal ) accedan a algo.