Qué modificador de acceso se puede aplicar al paquete. Modificadores de acceso. Privado, protegido, predeterminado, público. Control de acceso y herencia

Aquí intentaremos cubrir casi todos los casos de uso de modificadores de acceso. Las únicas excepciones son su uso para anidados ( anidado) e interno ( interno), así como para interfaces, ya que aún no hemos considerado estos temas.

Las clases y paquetes que se utilizan junto con los modificadores de acceso sirven como medios de encapsulación, es decir, un medio para ocultar los detalles de implementación detrás de una interfaz simple.

Los modificadores de acceso se pueden aplicar tanto a las clases como a sus miembros: campos y métodos. Hay cuatro modificadores de acceso en total, y aquí daremos una breve descripción de ellos, luego consideraremos cada uno en detalle.

• público- cualquier componente declarado como público, accesible desde cualquier código
• protegido- permite el acceso al componente dentro del paquete y clases de descendientes
• privado- permite el acceso a componentes dentro de la clase
• defecto(sin palabra clave): permite el acceso a los componentes dentro del paquete

Las clases heredadas son clases heredadas de una clase. Aún no hemos estudiado la herencia..

Acceso a clases

De forma predeterminada, las clases de nivel superior están disponibles en el paquete en el que están definidas.... Sin embargo, si la clase de nivel superior se declara como público entonces estará disponible en todas partes (o donde esté disponible el paquete). Hemos limitado esta declaración a las clases de nivel superior porque las clases se pueden declarar como miembros de otras clases. Dado que estas clases internas son miembros de la clase, obedecen las reglas para controlar el acceso a los miembros de la clase..

Accediendo a los miembros de la clase

Los miembros de la clase siempre están disponibles dentro del cuerpo de la clase. Defecto Los miembros de la clase también están disponibles en el paquete en el que se define la clase..

Modificador público

Para una clase que no está anidada, solo se puede especificar uno de los dos niveles de acceso posibles: dado defecto y público . Cuando la clase se declara como público, debería ser el único público la clase declarada en el archivo y el nombre del archivo deben coincidir con el nombre de la clase.

Cómo público se pueden declarar clases, campos, métodos y constructores.

Modificador protegido

Echaremos un vistazo más de cerca a este modificador en el tema de la herencia de clases. Si no se usa la herencia, este modificador funciona, al igual que el modificador predeterminado.

Lo único que se puede decir ahora brevemente es que los componentes declarados como protegido tendrá acceso cualquier clase secundaria de cualquier paquete o cualquier clase del mismo paquete.

Cómo protegido Se pueden declarar campos, métodos, constructores, clases anidadas e interfaces anidadas.

protegido .

Modificador privado

Este es el modificador más restrictivo en términos de restricción de acceso. Elementos declarados como privado son accesibles solo dentro de la misma clase y para nadie fuera de la clase.

Cómo privado Se pueden declarar campos, métodos, constructores, clases anidadas e interfaces anidadas.

Las clases e interfaces de nivel superior no se pueden declarar como privado .

Básicamente, los modificadores de acceso son un tema simple, pero volveremos a ellos más adelante. Si bien era solo un conocido. Y ahora un poco de práctica ...

Creé las clases Mod02.java, DefMod.java, ProMod.java y PrvMod.java que pertenecen al paquete pro.java.pkg002, así como la clase PubMod.java, que pertenece al paquete pro.java.pkg003. A continuación, solo daré capturas de pantalla de estas clases y el resultado del programa:

Hablaremos de modificadores: qué son modificadores, alcances, modificadores de clases, campos, métodos. Creo que no será aburrido.

Modificadores en Java Son palabras clave que dan ciertas propiedades a una clase, campo de clase o método.

Para indicar la visibilidad de una clase de sus métodos y campos, existen 4 modificadores de acceso:

• privado los miembros de la clase solo son accesibles dentro de la clase;
• paquete-privado o predeterminado (predeterminado) los miembros de la clase son visibles dentro del paquete;
• protegido los miembros de clase están disponibles dentro del paquete y en clases derivadas;
• público los miembros de la clase están disponibles para todos.

Si recuerdas, al final, cuando ya importamos la clase Cat, todavía teníamos un error de compilación.

El caso es que no hemos registrado ningún modificador de acceso a nuestros campos y métodos, y tienen una propiedad predeterminada (los miembros de la clase son visibles dentro del paquete). Para corregir el error de compilación de nuestro código y finalmente ejecutarlo, necesitamos hacer públicos nuestro constructor y nuestros métodos. Entonces se pueden llamar desde otros paquetes.

Puede empezar a preguntarse: ¿para qué sirve todo esto? ¿Por qué no hacer que el código sea visible desde cualquier paquete o clase, pero necesita diferenciar el acceso? Estas preguntas desaparecerán por sí solas cuando llegue el momento de escribir proyectos complejos y engorrosos. Ahora bien, cuando escribimos aplicaciones cuya funcionalidad se limita a una o dos clases, parece que no tiene sentido limitar nada.

Imagina que tienes una clase que muestra un objeto de producto. Por ejemplo, un coche. El coche puede tener un precio. Ha creado un campo de precio y muchos otros campos, un montón de métodos que son responsables de la funcionalidad. Todo parece ir bien. Su auto de clase es parte de un gran proyecto y todos están felices. Pero digamos que alguien, por error o intencionalmente, creó una instancia de la clase de automóvil y estableció un precio negativo. ¿Cómo puede un producto tener un precio negativo? Este es un ejemplo muy primitivo y es poco probable que suceda en la vida real, pero creo que la idea es clara. A veces es necesario dar acceso no directamente, sino a través de ciertos métodos. Puede ser que el código sea responsable de la funcionalidad de otro código y no desee que nadie cambie y edite parte del suyo. Por todo esto, existe una restricción de acceso.

El modificador de acceso para constructores, métodos y campos puede ser cualquier cosa. Una clase solo puede ser pública o predeterminada, y solo puede haber una clase pública en un archivo.

Por ahora, habrá suficiente sobre modificadores de acceso. En el artículo "Programación Orientada a Objetos" hablaremos de ellos con más detalle, pero ahora hablemos de otros modificadores de los cuales, por cierto, hay muchos.

Ahora el siguiente modificador es estático... Se puede usar frente a un método, campo e incluso una clase cuando queremos declarar una clase anidada. En Java, puede escribir clases dentro de otras clases, y si el modificador antes de la clase está dentro de la clase estática, dicha clase se llama anidada, si hay otro modificador o de forma predeterminada, dicha clase se llama interna. Habrá un artículo separado sobre clases anidadas e internas, ya que allí no todo es tan simple.

El modificador estático delante de un método o campo indica que no pertenece a una instancia de esta clase. ¿Qué significa esto para nosotros? Cuando describimos un campo o método de clase como estático, se puede llamar sin usar una instancia de la clase. Es decir, en lugar de esta construcción: Cat cat = new Cat (); cat.method (), puede escribir Cat.method (). Siempre que el método se declare estático. Las variables estáticas son las mismas para todos los objetos de la clase. Tienen un enlace.

Modificadores de clase pública (

static int anotherStaticField = 5;

public static void myStaticMethod () (

someField = "Mi campo";

// nonStaticField = ""; error de compilación

// no se pueden utilizar campos no estáticos

// en métodos estáticos

public void myNonStaticMethod () (

otherStaticField = 4; // se pueden usar campos estáticos

// en métodos no estáticos

// el método principal también tiene un modificador estático

nuevos Modificadores () .myNonStaticMethod ();

Modificators.myStaticMethod (); // llamar a métodos y campos estáticos

// a través de classname.method

Otra cosa importante a tener en cuenta sobre los modificadores estáticos es que los campos estáticos se inicializan en el momento de la carga de la clase. A menudo, en varios tipos de pruebas de Java, puede encontrar el siguiente código:

Pregunta: ¿qué se mostrará en la consola? Debe recordarse que el bloque estático se mostrará primero en cualquier caso. El siguiente será el bloque predeterminado. A continuación, mire la pantalla de la consola:

El siguiente modificador que veremos será final.

Creo que la palabra final habla por sí sola. Al aplicar el modificador final, dices que los campos no se pueden cambiar, los métodos se anulan y las clases no se pueden heredar (habrá un artículo separado sobre herencia). Este modificador se aplica solo a clases, métodos y variables (también a variables locales).

Hablaremos sobre el modificador final de métodos y clases en el artículo de OOP.

A continuación, habrá modificadores que no quedarán muy claros para los principiantes o quienes lean esta serie de artículos desde cero. Y aunque todavía no puedo explicarte todo (debido a que no conoces el material adjunto), te aconsejo que te familiarices con ellos. Cuando llegue el momento de utilizar estos modificadores, ya comprenderá la mayoría de los términos que se utilizan a continuación.

Modificador sincronizado: indica que el método solo puede ser utilizado por un hilo a la vez. Si bien es posible que esto no le diga nada, la utilidad de este modificador se verá a medida que aprendamos sobre el subproceso múltiple.

Modificador transitorio- dice que durante la serialización del objeto, se debe ignorar algún campo. Normalmente, estos campos almacenan valores intermedios.

Modificador volátil- utilizado para subprocesos múltiples. Cuando un campo con el modificador volátil será usado y cambiado por varios subprocesos, este modificador asegura que el campo cambiará a su vez y no habrá confusión con él.

Modificador nativo antes de la declaración del método indica que el método está escrito en otro lenguaje de programación. Generalmente en C.

Modificador estrictofp- Proporciona ejecución de operaciones sobre números de tipo float y double (punto flotante) según el estándar IEEE 754. O, más simplemente, garantiza que dentro de un método los resultados de los cálculos serán los mismos en todas las plataformas.

Todavía no he hablado del modificador abstracto... Te lo contaré en pocas palabras, porque sin el conocimiento básico de la programación orientada a objetos, no veo ningún sentido en hablar de ello.

No se puede crear una instancia de una clase que tiene el modificador abstracto. El único propósito es expandirse. Una clase abstracta puede contener tanto métodos abstractos como ordinarios.

Hablaremos más sobre el modificador abstracto en el artículo de OOP.

Con esto concluye el artículo sobre modificadores. No se ha dicho mucho sobre ellos. Pero esto se debe al hecho de que todavía no tenemos conceptos de programación orientada a objetos. En algunos artículos más, ampliaremos los modificadores y completaremos los espacios en blanco.

Primero, echemos un vistazo a los modificadores de acceso. Solo hay cuatro de ellos:

• privado los miembros de la clase solo son accesibles dentro de la clase
• paquete-privado o predeterminado (predeterminado) los miembros de la clase son visibles dentro del paquete
• protegido los miembros de la clase están disponibles dentro del paquete y en clases derivadas
• público los miembros de la clase están disponibles para todos

Durante la herencia, es posible cambiar los modificadores de acceso hacia MAYOR visibilidad.

El modificador de acceso para constructores, métodos y campos puede ser cualquiera, pero con las clases y sus bloques no es tan simple. Una clase solo puede ser pública o predeterminada, y solo puede haber una clase pública en un archivo. Un bloque solo puede tener un modificador: predeterminado.

Modificadores estáticos, abstractos y finales

Estático

• Se aplica a clases internas, métodos, variables y bloques lógicos.
• Las variables estáticas se inicializan en el momento de la carga de la clase.
• Las variables estáticas son las mismas para todos los objetos de la clase (misma referencia)
• Los métodos estáticos solo tienen acceso a variables estáticas
• Se puede acceder a los métodos y variables estáticos a través del nombre de la clase
• Los bloques estáticos se ejecutan en el momento de la carga de la clase.
• Los métodos no estáticos no se pueden anular como estáticos
• Las variables locales no se pueden declarar estáticas
• Los métodos abstractos no pueden ser estáticos
• Los campos estáticos no se serializan (solo cuando se implementa la interfaz serializable)
• Solo las variables de clase estáticas se pueden pasar al constructor con parámetros, llamadas a través de la palabra super (// parámetro //) o this (// parámetro //)

Abstracto

• Se aplica solo a métodos y clases
• Los métodos abstractos no tienen cuerpo de método
• Es lo opuesto a final: una clase final no se puede heredar, una clase abstracta debe heredar
• Una clase debe declararse abstracta si:

1. contiene al menos un método abstracto
2. no proporciona una implementación de métodos abstractos heredados
3. no proporciona una implementación de los métodos de la interfaz, cuya implementación ha declarado
4. es necesario prohibir la creación de instancias de la clase

Final

• Los campos no se pueden cambiar, los métodos se anulan
• Las clases no se pueden heredar
• Este modificador solo se aplica a clases, métodos y variables (también a variables locales)
• Los argumentos del método marcados como finales son de solo lectura, habrá un error en tiempo de compilación al intentar modificar
• Las variables finales no se inicializan de forma predeterminada, deben asignarse explícitamente un valor cuando se declaran o en un constructor, de lo contrario, un error de compilación
• Si la variable final contiene una referencia a un objeto, el objeto se puede modificar, pero la variable siempre se referirá al mismo objeto.
• Esto también es cierto para las matrices, porque las matrices son objetos, una matriz se puede cambiar y una variable siempre se referirá a la misma matriz.
• Si la clase se declara final y abstracta (conceptos mutuamente excluyentes), se producirá un error de compilación
• Dado que una clase final no se puede heredar, sus métodos nunca se pueden invalidar.

Constructor no puede ser estático, abstracto o final

Los modificadores nativos estrictos, transitorios, volátiles, sincronizados

Strictfp

• Se aplica a métodos y clases.
• Proporciona operaciones en números flotantes y dobles (punto flotante) de acuerdo con el estándar IEEE 754

Transitorio

• Solo aplicable para variables de nivel de clase (las variables locales no se pueden declarar como transitorias)
• Las variables transitorias pueden no ser definitivas o estáticas.
• Las variables transitorias no se serializan

Volátil

• Usado solo con variables
• Puede usarse con variables estáticas
• No se usa con variables finales: el valor de una variable declarada como volátil cambiado por un hilo se cambia de forma asíncrona para otros hilos
• Utilizado en aplicaciones de subprocesos múltiples

Sincronizado

• Se aplica solo a métodos o partes de métodos
• Se utiliza para controlar el acceso a partes importantes del código en programas multiproceso

Nativo

• Usado solo para métodos
• Indica que el método fue escrito en otro lenguaje de programación.
• Las clases en Java utilizan muchos métodos nativos para mejorar el rendimiento y el acceso al hardware.
• Es posible pasar / devolver objetos Java desde métodos nativos
• La firma del método debe terminar con ";", las llaves causarán un error de compilación

Funciones en interfaces

• Los métodos son siempre públicos y abstractos, incluso si no están declarados
• Los métodos no pueden ser estáticos, finales, estrictos, nativos, privados, protegidos
• Las variables son solo públicas estáticas finales, incluso si no se declaran
• Las variables no pueden ser estrictas, nativas, privadas, protegidas
• Solo puede heredar (extender) otra interfaz, no implementar una interfaz o clase (implementa).

Juntemos todos los modificadores:

	Clase	Clase interior	Variable	Método	Constructor	Bloque lógico
público	sí	sí	sí	sí	sí	No
protegido	No	sí (excepto para clases locales y anónimas)	sí	sí	sí	No
defecto	sí	sí		sí	sí	sí
privado	No	sí (excepto para clases locales y anónimas)	sí	sí	sí	No
final	sí		Sí (y para una variable local)	sí	No	No
abstracto	sí	Si (excepto para clases anónimas)	No	sí	No	No
estático	No	sí (excepto para clases locales y anónimas)	sí	sí	No	sí
nativo	No	No	No	sí	No	No
transitorio	No	No	sí	No	No	No
sincronizado	No	No	No	sí	No	Sí (solo como parte del método)
volátil	No	No	sí	No	No	No
estrictofp	sí	sí	No	sí	No	No

5

He visto algo de discusión en StackOverflow sobre este tema, pero no veo algo que me haya ayudado a entender el siguiente punto:

Vengo de C ++ y recientemente comencé a aprender Java. En C ++, cuando protegido, solo se usa una subclase que puede acceder al miembro (análogo a un campo en Java).

También hay clases de amigos en C ++ que pueden acceder a las cámaras privadas / protegidas de la clase, que dan amistad. Esto es un poco como el modificador de campo "paquete" en Java (el modificador de campo predeterminado), excepto que en C ++, la amistad da acceso a todos los miembros privados, pero en Java, el acceso desde las clases en un paquete es específico de la clase. campo.

Lo que no puedo entender, asumiendo que solo quiero proporcionar acceso a subclases, es lo que puedo hacer en C ++ al declarar miembros protegidos en una clase que no "da" amistades.

Pero en Java no sé cómo hacer esto, porque con la ayuda de un modificador de campo "protegido", también proporciono acceso a todas las clases en el paquete. La única forma en que lo encuentro es declarar un campo protegido y aislar la clase en su paquete.

De esto llego a la conclusión de que la agrupación de clases en un paquete debe realizarse en función de la "amistad" entre las clases. ¿Es este realmente el factor principal al agrupar paquetes?

Otra cosa que no entiendo, en Java, asumiendo que tengo dos campos en la clase A: b, c. Quiero darle acceso a B pero no a b, y quiero darle acceso a C pero no a b. ya la "Paz" quiero que b, c se esconda. ¿Cómo puedo hacer eso? Supongo que B, C deberían estar en el mismo paquete que A. pero declarando b, c con paquete con el modificador permito que B, C acceda tanto a b como a. ¿Hay alguna forma en Java de hacer esto?

Espero alguna explicación de esta pregunta.

11

Una pregunta mejor, si es menos útil, será más limitada y específica. La pregunta general "todo acerca de la privacidad en Java y C ++ y en qué se diferencian" es más que demasiado amplia. ¿Puede hacer una pregunta más específica sobre un problema más específico? - Yakk 04 mar 15 2015-03-04 16:38:58

• 4 respuestas

Clasificación:

Actividad

2

En C ++, cuando se usa seguridad, solo la subclase puede acceder al elemento (análogo a un campo en Java).

Los especificadores de acceso también son para funciones / métodos miembro, no solo para variables miembro.

En C ++ también hay clases de "amigos" que pueden acceder a los miembros privados / protegidos de la clase, lo que da "amistad". Este es un poco como el modificador de campo "paquete" en Java (el modificador de campo predeterminado), excepto que en C ++, la amistad da acceso a todos los miembros privados, pero en Java, el acceso desde clases en el mismo paquete es específico de el campo de la clase.

No solo hay clases de amigos, sino también funciones.

Es cierto que acceder a las partes privadas de Java es similar, pero no es un reemplazo completo. Es mejor decir que estas dos funciones tienen subconjunto los problemas que resuelven. Hay problemas que pueden ser resueltos por un amigo, pero no por un paquete privado y viceversa.

Lo que no pude entender, asumiendo que solo quiero proporcionar acceso a subclases, es lo que puedo hacer en C ++ al declarar a los usuarios protegidos en una clase que la amistad no "da".

Pero en Java, no sé cómo puedo hacer esto,

Respuesta: No puedes.

ya que con la ayuda de un modificador de campo "protegido", también proporciono acceso a todas las clases del paquete.

La única forma que puedo encontrar es declarar un campo protegido y tener la clase aislada en su paquete.

Técnicamente, sí. Pero esto crea otros problemas. Su clase ya no podrá acceder a las partes del paquete privado de su paquete anterior. Digamos que su BaseClass estaba en com.example.one. Lo moverá a com.example.two. Ahora ya no podrá acceder a otros paquetes de clase privada com.example.one.

¿Es este realmente el factor principal al agrupar paquetes?

Sí, Java está diseñado de esa manera. Puedes intentar luchar contra las reglas del idioma pero es una batalla perdida en cualquier lenguaje de programación.

Otra cosa que no entiendo en Java, asumiendo que tengo dos campos en la clase A: b, c. Quiero darle acceso a B pero no a b, y quiero darle acceso a C pero no a b. y en "Mundo" quiero que b, c se esconda. ¿Cómo puedo hacer eso?

No se puede hacer de una manera limpia (limpio, quiero decir: sin ningún truco que requiera que verifique la pila de llamadas en tiempo de ejecución y arroje excepciones).

Si está preocupado por este escenario porque está desarrollando una API pública, una solución de baja tecnología que generalmente funciona muy bien es crear uno o más paquetes * .internal y documentar claramente el hecho de que no deben usarse en el código del cliente.

1

Son un montón de preguntas juntas ...

Pero en Java, no sé cómo puedo hacer esto, ya que en virtud de usar un modificador de campo "protegido", también proporciono acceso a todas las clases en el paquete.

De hecho, no hay forma de proporcionar acceso solo a subclases, pero no a clases en el mismo paquete. Fue una decisión de diseño tomada hace siglos ...

La única forma en que lo encuentro es declarar un campo protegido y aislarlo en mi paquete.

Esto es técnicamente correcto, aunque será de poca utilidad. El ajuste de clases es para agrupar clases relacionadas, donde "hermanos" significa "clases que cumplen una relación particular", es decir, pertenecen al mismo caso de uso, pertenecen al mismo nivel arquitectónico, están en las mismas entidades, etc.

De esto llego a la conclusión de que la agrupación de clases en un paquete debe realizarse en función de la "amistad" entre las clases. ¿Es este realmente el factor principal al agrupar paquetes?

Creo que ya respondí a esto en el párrafo anterior: el empaque es para agrupar clases relacionadas de acuerdo con algunos criterios específicos.

Para sus clases A, B y C, por ejemplo con atributos:

Creo que B, C deberían estar ambos en el mismo paquete, A declarando b, con el modificador de empaquetado, dejo que B, C accedan a b y k.¿Hay alguna forma en Java de hacer esto?

La respuesta es no, no existe una manera fácil y limpia de hacer esto. Podrías lograr esto con algunos trucos o técnicas más avanzadas, pero nuevamente, esto fue parte de las decisiones tomadas por los diseñadores de lenguajes hace mucho tiempo ...

0

Respuesta corta: no hay forma de hacer esto.

Si le preocupa la intrusión de inyectar clientes de clase en un paquete para obtener acceso no autorizado, puede mover el código confidencial en un paquete separado y sellar el paquete en un frasco en el que lo entregue en: http://docs.oracle. com / javase / tutorial /deployment/jar/sealman.html

1

Se asume implícitamente que todas las clases de un paquete se "conocen" entre sí (porque fueron escritas por la misma persona / empresa / organización). De esta manera, o no tienen acceso a los campos protegidos o, si lo tienen, saben cómo hacerlo correctamente.

Se supone que las clases en el mismo paquete están más relacionadas entre sí que el padre con la clase derivada, porque la clase derivada podría estar escrita por otra persona. Entonces decidieron que la protección privada era más limitada que protegida.

Entonces, supongo que no tiene que preocuparse por cómo las clases en el mismo paquete pueden acceder a los campos de las demás. En general, simplemente no uso esta función, excepto cuando escribo iteradores.

Si tiene dos campos, puede convertirlos en clases internas para que tengan acceso a campos privados (nuevamente, lógica: si una clase está dentro de otra clase, conoce la semántica de esa clase) y puede exponer ese acceso a sus clases a través de métodos protegidos.

Por supuesto, puede crear un protocolo de intercambio de tokens complejo para hacer que este campo solo sea accesible para instancias B / C, pero eso sería una sobrecarga maravillosa y otro objeto aún puede usar la reflexión para acceder a todos los miembros privados si no lo deshabilita utilizando políticas de seguridad, que generalmente no es el caso, pero nuevamente, las políticas de seguridad las decide en última instancia el propietario de la JVM.

Entonces, en última instancia, la forma preferida de hacer lo que dice en Java es ponerlos en el mismo paquete o escribir B y C como clases internas de A para que puedan acceder directamente a los miembros privados de A y exponerlos como clases derivadas.

Clase pública A (clase abstracta estática pública B (protected Whatever getWhatever (A a) (return ab;) protected void setWhatever (A a, Whatever value) (ab = value;)) clase abstracta estática pública C (protected Whatever getWhatever (A a) (return ac;) protected void setWhatever (A a, Cualquiera valor) (ac = valor;)) privado Cualquiera b; privado Cualquiera c;)

una vez más, siempre piensas que las clases en el mismo paquete nunca harán nada malo.

Última actualización: 03.10.2019

Todos los miembros de una clase (campos, métodos, propiedades) todos tienen modificadores de acceso... Los modificadores de acceso le permiten establecer un ámbito válido para los miembros de la clase. Es decir, los modificadores de acceso definen el contexto en el que se puede utilizar una variable o un método determinados. En temas anteriores, ya lo hemos encontrado cuando declaramos que los campos de clase son públicos (es decir, con el modificador público).

Los siguientes modificadores de acceso se utilizan en C #:

public: un público, una clase pública o un miembro de una clase. Se puede acceder a dicho miembro de clase desde cualquier lugar del código, así como desde otros programas y ensamblados.

privado: una clase privada o miembro de una clase. Representa exactamente lo contrario del modificador público. Tal clase privada o miembro de clase solo es accesible desde el código en la misma clase o contexto.

protected: Se puede acceder a dicho miembro de clase desde cualquier lugar de la clase actual o en clases derivadas. Sin embargo, las clases derivadas se pueden ubicar en otros ensamblados.

interno: una clase y los miembros de una clase con un modificador similar son accesibles desde cualquier lugar del código en el mismo ensamblado, pero no está disponible para otros programas y ensamblados (como es el caso del modificador público).

protegido interno: combina la funcionalidad de dos modificadores. Las clases y los miembros de clase con este modificador están disponibles en el ensamblado actual y en las clases derivadas.

private protected: Se puede acceder a dicho miembro de clase desde cualquier lugar de la clase actual o en clases derivadas que se definen en el mismo ensamblado.

Podemos establecer explícitamente el modificador de acceso, por ejemplo:

Estado de clase privada protegida (internal int a; protected void Print () (Console.WriteLine ($ "a = (a)");))

O podemos omitir la especificación:

Estado de la clase (int a; void Print () (Console.WriteLine ($ "a = (a)");))

Si no se define ningún modificador de acceso para los campos y métodos, el modificador privado se utiliza para ellos de forma predeterminada.

Las clases y estructuras declaradas sin un modificador tienen acceso interno por defecto.

Todas las clases y estructuras que se definen directamente en espacios de nombres que no están anidados dentro de otras clases solo pueden tener modificadores públicos o internos.

Veamos un ejemplo y creemos la siguiente clase de estado:

Public class State (// es lo mismo que private int defaultVar; int defaultVar; // el campo es accesible solo desde la clase actual private int privateVar; // accesible desde la clase actual y las clases derivadas que están definidas en el mismo proyecto protegido private int protectedPrivateVar; // disponible de la clase actual y clases derivadas protected int protectedVar; // disponible en cualquier lugar del proyecto actual internal int internalVar; // disponible en cualquier lugar del proyecto actual y de clases heredadas en otros proyectos protected internal int protectedInternalVar; // disponible en cualquier parte del programa, así como para otros programas y ensamblajes public int publicVar; // por defecto tiene un modificador private void defaultMethod () => Console.WriteLine ($ "defaultVar = (defaultVar)"); / / el método es accesible solo desde la clase actual private void privateMethod () => Console.WriteLine ($ "privateVar = (privateVar)"); // accesible desde la clase actual y las clases derivadas que están definidas en el mismo párrafo vacío privado protegido protectedPrivateMethod () => Console.WriteLine ($ "protectedPrivateVar = (protectedPrivateVar)"); // accesible desde la clase actual y las clases derivadas protected void protectedMethod () => Console.WriteLine ($ "protectedVar = (protectedVar)"); // disponible en cualquier lugar del proyecto actual internal void internalMethod () => Console.WriteLine ($ "internalVar = (internalVar)"); // disponible en cualquier lugar del proyecto actual y de clases heredadas en otros proyectos protected internal void protectedInternalMethod () => Console.WriteLine ($ "protectedInternalVar = (protectedInternalVar)"); // disponible en cualquier parte del programa, así como para otros programas y ensamblajes public void publicMethod () => Console.WriteLine ($ "publicVar = (publicVar)"); )

Dado que la clase State se declara con el modificador público, será accesible desde cualquier lugar del programa, así como desde otros programas y ensamblados. La clase State tiene cinco campos para cada nivel de acceso. Más una variable sin modificador, que es privada por defecto.

También hay seis métodos que mostrarán los valores de los campos de clase en la pantalla. Tenga en cuenta que, dado que todos los modificadores le permiten usar miembros de clase dentro de esta clase, todas las variables de clase, incluidas las privadas, están disponibles para todos sus métodos, ya que todas están en el contexto de la clase State.

Ahora veamos cómo podemos usar las variables de nuestra clase en el programa (es decir, en el método Main de la clase Program), si las clases State y Program están en el mismo proyecto:

Class Program (static void Main (string args) (State state1 = new State (); // no podremos asignar el valor a la variable defaultVar, // ya que tiene un modificador privado y la clase Program no ve it // Y el entorno lo subrayará como state1.defaultVar = 5; // Error, no puede obtener acceso // Lo mismo se aplica a la variable privateVar state1.privateVar = 5; // Error, no puede obtener acceso // asignar el valor de la variable protectedPrivateVar no funcionará, // ya que la clase Program no es una subclase de la clase State state1.protectedPrivateVar = 5; // Error, no puede obtener acceso // la asignación del valor de la variable protectedVar también fallará , // dado que la clase Program no es una subclase de la clase State state1.protectedVar = 5; // Error, no puede obtener acceso // la variable internalVar con el modificador interno es accesible desde cualquier lugar del proyecto actual // por lo tanto, asígnele con seguridad el valor state1.internalVar = 5; // la variable protectedInternalVar también es accesible desde cualquier lugar del proyecto actual state1.protectedInternalVar = 5; // publicVar está disponible públicamente state1.publicVar = 5; ))

Así, pudimos configurar solo las variables internalVar, protectedInternalVar y publicVar, ya que sus modificadores nos permiten usarlas en este contexto.

La situación es similar con los métodos:

Class Program (static void Main (string args) (State state1 = new State (); state1.defaultMethod (); // Error, no se puede acceder a state1.privateMethod (); // Error, no se puede acceder a state1.protectedPrivateMethod () ; // Error, no puede obtener acceso state1.protectedMethod (); // Error, no puede obtener acceso state1.internalMethod (); // normas state1.protectedInternalMethod (); // normas state1.publicMethod (); // normas ))

Aquí, solo tres métodos estaban disponibles para nosotros: internalMethod, protectedInternalMethod, publicMethod, que tienen los modificadores internal, protected internal y public, respectivamente.

Gracias a este sistema de modificadores de acceso, es posible ocultar algunos aspectos de la implementación de la clase de otras partes del programa.

A pesar de que los modificadores públicos e internos son similares en su acción, tienen una gran diferencia. Las clases y los miembros de la clase con el modificador público también estarán disponibles para otros programas si la clase dada se coloca en la biblioteca dinámica dll y luego se usa en estos programas.