¿Por qué el modificador “protegido” en Java permite el acceso a otras clases en el mismo paquete?

¿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)

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.

Los modificadores están bien descritos en http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html . A partir de ahí vemos esta figura.

Modifier Class Package Subclass World public YYYY protected YYYN no modifier YYNN private YNNN 

A partir de esto, el motivo de la decisión de diseño es obvio: es tener una buena matriz simétrica.

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.

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.

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

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 scope predeterminado.

Una subclase puede residir fuera del paquete, siguiendo los niveles de scope de nuevo: privado <(predeterminado) Java no contradice sus propias directrices . Por lo tanto, un miembro protegido estará disponible en el scope predeterminado. También: clase

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