@ Nikita Rybak Antwort hat gute Punkte, aber Mangel an Details, ich kann nicht einfach auf die Idee kommen, ohne tief selbst nachzudenken, das Folgende ist, was ich dachte und jetzt sollte ich den Grund vollständig verstehen.
Bei vier Zugriffsmodifikatoren wird davon ausgegangen, dass die 1. Ebene öffentlich und die 4. Ebene privat ist (basierend auf dieser Tabelle nacheinander). Das erste, was wir wissen sollten, ist, warum Klasse auf oberster Ebene nicht als privat definiert werden kann.
Also, wenn "private class foo" (ein privates Mitglied definiert, dh die Klasse selbst ist ein Mitglied) erlaubt, was ist das Äußere (das das Mitglied enthält)? Dateibereich? Nein, die äußere Datei ist sinnlos, da sogar mehrere Klassen in einer Datei in separate Klassendateien kompiliert werden. Das Äußere ist also ein Paket . Der Standardzugriffsmodifikator der 3. Ebene bedeutet jedoch bereits "paketprivat ". Daher wird der Modifikator für den privaten Zugriff der 4. Ebene nicht verwendet / zugelassen.
Eine verschachtelte private Klasse ist jedoch zulässig, da die direkte äußere Klasse eine Klasse ist, kein Paket, z .
class PrivateNestedMain {
private static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
Was ist nun, wenn "protected class foo" dies zulässt? Das geschützte Hauptmerkmal ist die Unterklasse, daher sollte das äußere (Paket) (aufgrund des Umfangs, aber immer noch optional) den Stil der Unterklasse , dh des Unterpakets, oder package A extends package B, aber wir wissen nichts davon, angeben. So kann protected nicht das volle Potenzial (der Hauptbereich ist unterklassenweit) in der obersten Ebene nutzen, in der das äußere Paket enthalten ist (dh keine solche Unterpaket-Sache), aber protected kann das volle Potenzial in verschachtelten Klassen nutzen, in denen das äußere Paket ist ( dh kann Unterklasse sein) :
class ProtectedNestedMain {
protected static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
Beachten Sie, dass das oben Gesagte "kann nicht das volle Potenzial ausschöpfen", da es nicht die gesamte Unterklasse erreichen kann, nur weil keine äußere Unterklasse vorhanden ist. Dies bedeutet, dass tatsächlich geschützt werden kann . Es ist nur eine Frage der Wahl, um zu vermeiden, dass der Job des Pakets doppelt ausgeführt wird -privat, wenn äußere nicht unterklassenfähig sind , siehe unten.
Meine Verwirrung wird hauptsächlich durch die berühmte Tabelle unter https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html verursacht :
Wenn die 1. Ebene (öffentlich) und die 3. Ebene (paketprivat) erlaubt sind, wie um alles in der Welt ist die dazwischen liegende 2. Ebene (geschützt) nicht erlaubt?
öffentliche Unterstützung Unterklasse so leicht irreführend. Die richtige Art, diese Tabelle zu lesen, ist
öffentliche Unterstützungsunterklasse, wenn die äußere Unterklassenfunktion hat.
Die gleiche Irreführung gilt für package-private, package-private unterstützt keine Unterklasse ( N in Zelle) bedeutet nicht, dass das Unterklassenkonzept in Outer gilt.
Dass die Mittel sollten wir die ignorieren Subklassen - Spalte , wenn Unterklasse - Funktion nicht verfügbar in Außen ist:
Wie wir jetzt sehen können, sind sowohl geschützt als auch paketprivat jetzt dieselbe Ebene ( YYN ), keine Verwirrung mehr darüber, warum eine Zwischenebene nicht zulässig ist. Insgesamt wählt Java nur package-private über protected aus, um Verwirrung zu vermeiden ( es ist nur eine Frage der Wahl , aber das geschützte Hauptmerkmal ist die Unterklasse, sodass package-private überlegen ist), und das Ergebnis sind nur 2 Zugriffsmodifikatoren in der obersten Ebene zulässig:
Auf der obersten Ebene - öffentlich oder paketprivat (kein expliziter Modifikator).