what non means loop does java inheritance protected

non - repeat java



¿Por qué el modificador "protegido" en Java permite el acceso a otras clases en el mismo paquete? (6)

¿Cuál es la razón por la que en Java, un miembro con un modificador "protegido" no solo puede acceder a la misma clase y por subclases, sino también a todos en el mismo paquete?

Me pregunto sobre los motivos del diseño del lenguaje, no las aplicaciones reales (por ejemplo, las pruebas)

Básicamente tiene que ver con la vista de un paquete como una unidad controlada por API (de ahí la recomendación de iniciar su paquete con su nombre de dominio - unicidad global garantizada), por lo que la visibilidad crece desde privada -> paquete-privada -> protegida -> pública . Si la protección no fuera un aumento sobre el paquete privado, sino un tipo diferente de visibilidad, debería haber alguna manera de combinar los dos tipos de visibilidad cuando sea necesario.

Dado niveles progresivos de acceso, privado, paquete, protegido y público, sería innecesariamente limitante si se protegiera el paquete, ya que eso me obligaría a permitir el acceso a subclases para otorgar a otros miembros del mismo paquete. Sin embargo, intuitivamente, debería ser que otras clases en el mismo paquete son más confiables que otras clases "por ahí". De modo que está protegido entre el paquete y el público, ya que permite una exposición más amplia de acceso.

Creo que la razón básica se basa en la intuición de que hay un nivel básico de "confianza" entre las clases en el mismo paquete; razonablemente puede esperar que hagan lo correcto entre ellos, en la mayoría de los casos, el paquete será responsabilidad de un solo ingeniero o equipo, por lo que debe haber una armonía de diseño consistente.

En Java 1.0 había un quinto modificador de acceso: private protected . Esto estaba protected sin el acceso predeterminado. Aparentemente, nunca funcionó correctamente y se eliminó en 1.1. Por lo tanto, parece que los reclamos de que el protected se define de la manera en que lo hace el pedido total parecen ser espurios. El modificador de acceso a module en Java 7 tiene algunas preguntas de diseño en esta área.

Dado que se pensó que sería una buena idea que el modificador de acceso predeterminado para los miembros fuera "paquete privado", parece razonable que el nivel de protected debería haber sido al menos este nivel de acceso. Por mi dinero, protected no paga en absoluto en el idioma.

Este diseño se basa en la idea de que el paquete es la unidad apropiada, mantenida y lanzada por un equipo internamente consistente; las relaciones de herencia tienen mucho menos que ver con quién está manteniendo y liberando qué cuándo.

Java sigue sus principios de diseño en sí mismo. ¿Qué sucede cuando intentas reducir / reducir el alcance del método público en una subclase? uno obtiene un error. Siguen los niveles de los modificadores del alcance de Java: privado <(predeterminado) <protegido <público

Se supone que todas las clases en paquete son amigables porque trabajan juntas. Para que un miembro esté disponible en el paquete, se define en el alcance predeterminado.

Una subclase puede residir fuera del paquete, siguiendo los niveles de alcance de nuevo: privado <(predeterminado) <protegido <público: no podemos reducir el alcance. Protegido es un ámbito más amplio que el predeterminado, por lo que Java no contradice sus propias directrices . Por lo tanto, un miembro protegido estará disponible en el alcance predeterminado. También: clase <paquete <Proyecto.

No limite los modificadores solo a la visibilidad, pero la herencia y la estructura también funcionan al mismo tiempo y añádalas a la imagen también. Si esto fuera cierto: privado <protegido <(predeterminado) <público. entonces todas las subclases tendrían que residir en el mismo paquete, entonces, por qué necesita heredar, puede acceder a todo, ya que el ámbito predeterminado está disponible en el nivel de paquete. El alcance predeterminado habría perdido su valor, al igual que la herencia.