Java: Dostęp do podklasy bez dostępu do pakietów

Question

Jest dość nowy w Javie, ale zastanawiam się, dlaczego dostęp do pakietu jest uważany za "bardziej restrykcyjny" niż dostęp do podklasy. Oznacza to, że każdy modyfikator dostępu, który zapewnia podklasom dostęp do elementu, zapewnia także cały pakiet z dostępem i istnieją modyfikatory, które zapewniają dostęp do pakietu, ale nie podklasy.

Czy to nie jest całkowicie wstecz? Powiedzmy, że mam klasę ControlledInstantiation w jakiejś paczce. Jeśli mam inną klasę, funkcja ControlControlledInstantiation rozszerza ControlledInstantiation, nie mogę wywołać konstruktora ControlledInstantiation, chyba że ustawię go jako chroniony lub publiczny. I jeśli ustawię go na chroniony, teraz każda inna klasa w pakiecie może utworzyć go tak często, jak mu się podoba. Zatem coś, co jest obowiązkowe, aby mogło być substytutem swojej nadklasy (i syntaktycznie jest), uzyskuje taki sam lub mniejszy dostęp do nadklasy niż coś, co służy odrębnej, ale pokrewnej funkcji. To tak, jakby powiedzieć dziecku, że nie może bawić się portfelem, ponieważ nie pozwoliłbyś, aby twoi sąsiedzi to zrobili, a potem pozwolili twoim sąsiadom spać w twoim domu, ponieważ twoje dziecko to robi.

Sądzę, że pytam, co uzasadniało tę decyzję i jak mogę ją obejść?

Answer 1

Początkowo może się wydawać, że jest w tył, ale chodzi o to, że pakiet Java powinien zawierać zestaw stosunkowo spójnych klas, które są semantycznie powiązane, co znajduje odzwierciedlenie w domyślnym modyfikatorze pakietu. Logika jest taka, że ​​jeśli chcesz pójść o krok dalej i zezwolić na podklasy z dowolnej paczki, aby zobaczyć swoich członków, możesz zadeklarować je jako chronione. Czy ma to dla ciebie sens, że podklasy z obcych pakietów powinny być mniej zaufane niż jakakolwiek klasa (czy to podklasa czy nie) z twojego własnego pakietu?

Java rzeczywiście miała jeden prywatny chroniony modyfikator, który pozwoliłby osiągnąć to, czego szukasz, ale został usunięty, jak sądzę, ponieważ wprowadził w błąd ludzi. Nie jestem pewien, w jaki sposób można to osiągnąć, bez relegowania każdej pary klas/podklas do własnego pakietu. Ale to niechlujne rozwiązanie, które jest sprzeczne z zasadami Javy, i tak nie będzie działało dla hierarchii dziedziczenia więcej niż dwóch klas.

Answer 2

Masz rację, ten fakt jest trochę zagmatwany. Oto obejścia, które mogę zasugerować.

1. Twój przykład z chronionym konstruktorem jest bardziej odpowiedni dla metod. W niektórych przypadkach można uniknąć dostępu do chronionego konstruktora przez członka pakietu, które nie są podklasami bieżącej klasy, jeśli oznaczysz klasę jako streszczenie.

2. Jeśli naprawdę chcesz uniknąć dostępu do metody chronione przez członków zorganizowanych można rozwiązać ten problem, przynajmniej w czasie wykonywania przy użyciu 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

można uszczelnić pakiet. Zobacz specyfikację pliku JAR.