Java: Acceso a la subclase sin acceso al paquete

Question

Bastante nuevo en Java, pero me pregunto por qué el acceso al paquete se considera "más restrictivo" que el acceso a la subclase. Es decir, cada modificador de acceso que proporciona subclases con acceso a un miembro también proporciona acceso a todo el paquete, y existen modificadores que proporcionan acceso de paquete pero no acceso de subclase.

¿No es esto totalmente al revés? Digamos que tengo una clase ControlledInstantiation en algún paquete. Si tengo otra clase AlsoControlledInstantiation extends ControlledInstantiation, no puedo llamar al constructor de ControlledInstantiation a menos que lo configure como protegido o público. Y si lo configuro como protegido, ahora cualquier otra clase en el paquete puede instanciarlo tan a menudo como quiera. Entonces, algo que está obligado a ser sustituible por su superclase (y, sintácticamente, es) obtiene el mismo o menor acceso a la superclase que algo que cumple una función distinta pero relacionada. Es como decirle a su hijo que no puede jugar con su billetera porque no le permite a sus vecinos hacerlo y luego dejar que sus vecinos duerman en su casa porque su hijo sí.

Así que supongo que estoy preguntando, ¿qué motivó esta decisión y cómo puedo evitarla?

Answer 1

Al principio puede parecer al revés, pero la idea es que un paquete de Java debe contener un conjunto de clases comparativamente cohesivas que están semánticamente relacionadas, y esto se refleja en el modificador de paquete predeterminado. Entonces, la lógica es que si desea dar un paso más y permitir que las subclases de cualquier paquete visualicen sus miembros, puede declararlas como protegidas. ¿Tiene sentido para usted que las subclases de paquetes extranjeros sean menos confiables que cualquier clase (ya sea una subclase o no) de su propio paquete?

Java de hecho tenía una vez privado protegido modificador que conseguiría lo que busca, pero fue eliminado, me imagino, porque confundía a la gente. No estoy seguro de cómo podría lograr esto sin relegar cada par de clase/subclase a su propio paquete. Pero esa es una solución desordenada que va en contra de los principios de Java y de todos modos no funcionaría para las jerarquías de herencia de más de dos clases.

Answer 2

Tiene razón, este hecho es un poco confuso. Aquí están las soluciones alternativas que puedo sugerir.

1. Su ejemplo con constructor protegido es más relevante para los métodos. En algunos casos, puede evitar el acceso al protegido constructor por miembro del paquete que no son las subclases de la clase actual si marca clase como abstract.

2. Si realmente desea evitar el acceso al método protegido por miembros de paquetes se puede resolver este problema al menos en tiempo de ejecución utilizando Throwable.getStackTrace():

   if(!getClass().isAssignableFrom(
       Class.forName(new Throwable().getStackTrace()[1].getClassName()))) { 
        throw new IllegalAccessException(
         "This method can be accessed by subclass only"); 
   } 
   

Answer 3

Puede sellar un paquete. Ver la especificación del archivo JAR.