La réponse de @Nikita Rybak a de bons points mais manque de détails, je ne peux pas simplement avoir l'idée sans réfléchir profondément moi-même, ce qui suit est ce que j'ai pensé et maintenant je devrais comprendre complètement la raison.
Quatre modificateurs d'accès, supposons que le 1er niveau est public et le 4ème niveau est privé (basé sur ce tableau dans l'ordre). La première chose que nous devons savoir est pourquoi la classe ne peut pas être définie comme privée au niveau supérieur.
Donc, si "private class foo" (Un membre privé défini, c'est-à-dire que la classe elle-même est un membre) le permet, quel est l'externe (qui contient le membre)? Portée du fichier? Non, le fichier externe est inutile car même plusieurs classes dans un seul fichier seront compilées dans des fichiers de classe séparés. Donc, l'extérieur est le paquet . Mais le modificateur d'accès par défaut de 3ème niveau signifie déjà "package-private ". Ainsi, le modificateur d'accès privé de 4ème niveau ne sera pas utilisé / autorisé.
Mais la classe privée imbriquée est autorisée car l'externe direct est la classe, pas le package, par exemple :
class PrivateNestedMain {
private static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
Et si la "classe protégée foo" le permettait? La caractéristique principale protégée est la sous-classe, donc le (package) externe DEVRAIT (en raison de sa portée, mais c'est toujours facultatif) fournir un style de sous - classe , c'est-à-dire sous-package, ou package A extends package B, mais nous ne savons rien de tel. Ainsi, protected ne peut pas utiliser le plein potentiel (la portée principale est à l'échelle de la sous-classe) au niveau supérieur dont le package externe est (c'est-à-dire pas de sous-package), mais protected peut utiliser le plein potentiel dans la classe imbriquée dont l'extérieur est la classe ( ie peut être une sous-classe) :
class ProtectedNestedMain {
protected static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
Notez que ce qui précède dit "ne peut pas utiliser le plein potentiel" car il ne peut pas atteindre toute la sous-classe simplement parce qu'aucune sous-classe externe, c'est-à-dire que la protection réelle peut être autorisée , c'est juste une question de choix pour éviter de dupliquer le travail du package -privée si externe non sous-classable , voir ci-dessous.
Ma confusion est principalement causée par la célèbre table à https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html :
Si le 1er niveau (public) et le 3ème niveau (forfait privé) sont autorisés, comment diable le 2ème niveau intermédiaire (protégé) n'est-il pas autorisé?
sous-classe de soutien public si facile à induire en erreur. La bonne façon de lire ce tableau est
public prend en charge la sous-classe si la sous-classe externe a une fonction de sous-classe.
La même erreur s'applique à package-private, package-private ne prend pas en charge la sous-classe ( N dans la cellule) ne signifie pas que le concept de sous-classe s'applique à l'extérieur.
Cela signifie que nous devons ignorer la colonne Sous -classe si la fonctionnalité de sous-classe n'est pas disponible en externe:
Comme nous pouvons le voir maintenant, les deux niveaux protégés et privés sont au même niveau maintenant ( YYN ), plus aucune confusion sur la raison pour laquelle le niveau intermédiaire n'est pas autorisé. Dans l'ensemble, Java ne choisit que package-private sur protected pour éviter toute confusion ( c'est juste une question de choix , mais la caractéristique principale protégée est la sous-classe, donc package-private est supérieur), et le résultat , seuls 2 modificateurs d'accès sont autorisés au niveau supérieur:
Au niveau supérieur: public ou package-private (pas de modificateur explicite).