La risposta di @Nikita Rybak ha buoni punti ma mancanza di dettagli, non posso semplicemente avere l'idea senza pensarci profondamente, quanto segue è quello che ho pensato e ora dovrei capire completamente il motivo.
Quattro modificatori di accesso, assumono che il 1 ° livello sia pubblico e il 4 ° livello sia privato (in base a questa tabella in sequenza). La prima cosa che dovremmo sapere è perché la classe non può essere definita come privata nel primo livello.
Quindi, se "private class foo" (un membro privato definito, cioè la classe stessa è un membro) lo consente, qual è l'esterno (che contiene il membro)? Ambito del file? No, il file esterno è inutile perché anche più classi in un singolo file verranno compilate in file di classe separati. Quindi l'esterno è il pacchetto . Ma il modificatore di accesso predefinito di 3 ° livello significa già "pacchetto privato ". Quindi il modificatore di accesso privato di 4 ° livello non sarà utilizzato / consentito.
Ma la classe privata annidata è consentita perché l'esterno diretto è la classe, non il pacchetto, ad esempio :
class PrivateNestedMain {
private static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
E se la "classe protetta pippo" lo permettesse? La caratteristica principale protetta è la sottoclasse, quindi il (pacchetto) esterno DOVREBBE (a causa dell'ambito fino a, ma è comunque opzionale) fornire lo stile della sottoclasse , cioè il sotto-pacchetto, o package A extends package B, ma non sappiamo nulla del genere. Quindi protected non può utilizzare il pieno potenziale (l'ambito principale è a livello di sottoclasse) nel livello superiore che l'esterno è il pacchetto (cioè nessuna cosa del sotto-pacchetto), ma protected può usare tutto il potenziale nella classe annidata che l'esterno è class ( ie può essere una sottoclasse) :
class ProtectedNestedMain {
protected static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
Nota che quanto sopra detto "non può usare il pieno potenziale" perché non può raggiungere l'intera sottoclasse semplicemente perché nessuna sottoclasse esterna, ciò significa che può essere effettivamente protetta , è solo una questione di scelta evitare di duplicare il lavoro del pacchetto -privato se esterno non è sottoclasse , vedi sotto.
La mia confusione è principalmente causata dalla famosa tabella su https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html :
Se il 1 ° livello (pubblico) e il 3 ° livello (pacchetto privato) sono consentiti, come mai il 2 ° livello intermedio (protetto) non è consentito?
sottoclasse di sostegno pubblico così facile da fuorviare. Il modo corretto per leggere questa tabella è
sottoclasse di supporto pubblico se l'esterno ha la funzione di sottoclasse.
Lo stesso fuorviante si applica a pacchetto-privato, pacchetto-privato non supporta la sottoclasse ( N nella cella) non significa che il concetto di sottoclasse si applica in esterno.
Ciò significa che dovremmo ignorare la colonna Sottoclasse se la funzione sottoclasse non è disponibile in esterno:
Come possiamo vedere ora, sia il livello protetto che quello privato del pacchetto sono allo stesso livello ora ( YYN ), non c'è più confusione sul motivo per cui il livello intermedio non è consentito. Nel complesso, Java sceglie solo il pacchetto privato rispetto a quello protetto per evitare confusione ( è solo una questione di scelta , ma la caratteristica principale protetta è la sottoclasse, quindi il pacchetto privato è superiore), e il risultato , solo 2 modificatori di accesso consentiti nel livello superiore:
Al livello superiore: pubblico o pacchetto privato (nessun modificatore esplicito).