C# 7.2 introduce el modificador private protected .
Siempre he protegido el acceso a los campos con propiedades, lo que permite el acceso a través de los métodos Get/Set, ya que normalmente no quiero que el estado interno de mi objeto sea modificado por nada que no sea mi propia clase.
Estoy tratando de entender por qué el equipo de lenguaje C# ha agregado esta función. Después de una extensa búsqueda en Google, y de leer y mirar los medios de 'qué hay de nuevo' (he visto el comunicado de prensa , los detalles y el video de Mads Torgerson ), todavía no soy más sabio.
Para mí, esto parece permitir que un desarrollador rompa el principio de sustitución de Liskov, pero esto puede deberse a que no entiendo por qué existe esta función ahora.
Entiendo cómo se puede usar, pero no por qué: ¿alguien puede proporcionar un ejemplo de uso del mundo real en lugar del artificial en los documentos de MSDN?
Para los modificadores de acceso de dos palabras , tengo este concepto: el primer acceso está relacionado con otro ensamblaje, el segundo con ese ensamblaje en el que se definió.
interno protegido
protegido en otra asamblea: accesible solo en las clases secundarias.
interno en el ensamblaje actual: accesible para todos en el ensamblaje actual.
privado protegido
Antes de C# 7.2, teníamos un modificador protected internal . Esto realmente significa protegido O interno, es decir, el miembro A es accesible para las clases secundarias y también para cualquier clase en la asamblea actual, incluso si esa clase no es secundaria de la clase A (por lo que la restricción implícita en "protegido" se relaja).
private protected realmente significa protegido E interno. Es decir, el miembro solo es accesible para las clases secundarias que están en el mismo ensamblaje, pero no para las clases secundarias que están fuera del ensamblaje (por lo que la restricción implícita en "protegido" se reduce, se vuelve aún más restrictiva). Eso es útil si crea una jerarquía de clases en su ensamblaje y no desea que ninguna clase secundaria de otros ensamblajes acceda a ciertas partes de esa jerarquía.
Podemos tomar el ejemplo que Jon Skeet proporcionó en los comentarios . Supongamos que tienes clase
public class MyClass { }Y desea poder heredar de él solo en el ensamblaje actual, pero no desea permitir instanciar esta clase directamente, excepto desde dentro de esta jerarquía de clases.
La herencia solo dentro del ensamblaje actual se puede lograr con un constructor interno
public class MyClass { internal MyClass() { } }La prevención de la instanciación directa, excepto dentro de la jerarquía de clases actual, se puede lograr con el constructor protegido:
public class MyClass { protected MyClass() { } } Y para obtener ambos, necesita un constructor private protected :
public class MyClass { private protected MyClass() { } }Supongamos que tiene una clase interna llamada SomeHelper que desea usar como parte de la implementación de una clase base abstracta pública:
public abstract class Test { // Won't compile because SomeHelper is internal. protected SomeHelper CreateHelper() { return new SomeHelper(); } public int Func(int x) { var helper = CreateHelper(); return helper.DoSomething(x); } } internal class SomeHelper { public virtual int DoSomething(int x) { return -x; } } Esto no se compilará porque no puede tener un método protegido que devuelva un tipo interno. Su único recurso es no usar SomeHelper de esa manera, o hacer público SomeHelper .
(Podría convertir a SomeHelper en una clase interna protegida de Test , pero eso no funcionará si SomeHelper está destinado a ser utilizado por otras clases que no se derivan de la clase base).
Con la introducción de la función de private protected , puede declarar CreateHelper() así:
private protected SomeHelper CreateHelper() { return new SomeHelper(); }Ahora se compilará y no tendrá que exponer sus partes internas.