Pourquoi une classe ne peut-elle pas être définie comme protégée ?

Question

Pourquoi ne pouvons-nous pas définir une classe comme protected ?

Je sais qu'on ne peut pas, mais pourquoi ? Il devrait y avoir une raison spécifique.

Answer 1

Parce que ça n'a aucun sens.

Le membre protégé d'une classe (méthode ou variable) est identique au package-private (visibilité par défaut), sauf qu'il est également accessible depuis les sous-classes.
Puisqu'il n'existe pas de concept de "subpackage" ou de "package-inheritance" en Java, déclarer une classe protégée ou un package-private reviendrait au même.

Vous pouvez cependant déclarer les classes imbriquées et internes comme étant protégées ou privées.

Answer 2

Comme vous le savez, default est pour l'accès au niveau du paquetage et protected est pour le niveau du paquetage plus les classes non-package mais qui étendent cette classe (le point à noter ici est que vous pouvez étendre la classe seulement si elle est visible !) Présentons les choses de cette façon :

• Une classe de niveau supérieur protégée serait visible par les classes de son paquetage.
• Maintenant, le rendre visible en dehors du paquet (sous-classes) est un peu confus et délicat. Quelles classes devraient être autorisées à hériter de notre classe protégée ?
• Si toutes les classes sont autorisées à se sous-classer, cela sera similaire au spécificateur d'accès public.
• S'il n'y en a pas, il est similaire à celui par défaut.

Puisqu'il n'y a aucun moyen de restreindre cette classe à être sous-classée par seulement quelques classes (nous ne pouvons pas restreindre une classe à être héritée par seulement quelques classes parmi toutes les classes disponibles dans un paquetage/hors d'un paquetage), il n'y a aucune utilité des spécificateurs d'accès protégé pour les classes de niveau supérieur. Il n'est donc pas autorisé.

Answer 3

public class A
{
    protected class B
    {
    }
}

Answer 4

La définition d'un champ protégé rend ce champ accessible à l'intérieur du package ainsi qu'à l'extérieur du package par héritage uniquement (uniquement à l'intérieur de la classe enfant).

Ainsi, si nous sommes autorisés à rendre une classe protégée, nous pouvons y accéder à l'intérieur du paquet très facilement, mais pour accéder à cette classe en dehors du paquet, nous devons d'abord étendre l'entité dans laquelle cette classe est définie, c'est-à-dire son paquet.

Et puisqu'un paquetage ne peut pas être étendu (il peut être importé), définir une classe protected rendra à nouveau le paquetage privé, ce qui revient à le définir par défaut, ce que nous pouvons déjà faire. Il n'y a donc aucun avantage à définir une classe private, cela ne fera que rendre les choses ambiguës.

Pour plus d'informations, lisez Pourquoi une classe Java externe ne peut pas être privée ou protégée

Answer 5

Réponse de @Nikita Rybak a de bons points mais manque de détails, je ne peux pas simplement avoir l'idée sans penser profondément moi-même, ce qui suit est ce que je pensais et maintenant je devrais complètement comprendre la raison.

Quatre modificateurs d'accès, en supposant que le 1er niveau est public et le 4ème niveau est privé (sur la base de ce qui suit tableau dans la séquence). La première chose que nous devons savoir est pourquoi une 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) est autorisé, quel est l'extérieur (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 un paquet . Mais le 3ème niveau Le modificateur d'accès par défaut signifie déjà "paquet-privé". ". Le modificateur d'accès privé de 4ème niveau ne sera donc pas utilisé/autorisé.

Mais classe privée imbriquée est autorisé parce que l'extérieur direct est la classe, et non le paquet, par exemple :

class PrivateNestedMain {
    private static class Inner {
        public static void main(String[] args) {
            System.out.println("Hello from Inner!");
        }
    }
}

Et si "protected class foo" permettait ? protected caractéristique principale est une sous-classe, donc le paquet externe DEVRAIT (en raison de l'étendue du champ d'application, mais c'est toujours optionnel) fournir style de sous-classe c'est-à-dire un sous-paquet, ou bien package A extends package B mais nous ne savons rien de tel. Donc protected ne peut pas utiliser le plein potentiel (la portée principale est à l'échelle de la sous-classe) dans un niveau supérieur dont l'extérieur est un paquet (c'est-à-dire qu'il n'y a pas de tel sous-paquet), mais protected peut utiliser le plein potentiel dans une classe imbriquée dont l'extérieur est une classe (c'est-à-dire qu'elle 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 est dit ci-dessus "ne peut pas utiliser son plein potentiel" parce qu'il ne peut pas atteindre la sous-classe entière simplement parce qu'il n'y a pas de sous-classe extérieure, c'est à dire effectivement protégé peut être autorisé , c'est juste une question de choix pour éviter de dupliquer le travail de package-private si outer n'est pas sous-classable voir ci-dessous.

Ma confusion est principalement causée par la fameuse table à https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html :

Si le premier niveau (public) et le troisième niveau (privé) sont autorisés, comment se fait-il que le deuxième niveau (protégé) ne soit pas autorisé ?

sous-classe de support public, donc facile à tromper. La façon correcte de lire ce tableau est

support public de sous-classe si l'extérieur a la caractéristique de sous-classe.

Les mêmes tromperies s'appliquent à package-private, package-private ne supporte pas subclass ( N dans la cellule) ne signifie pas que le concept de sous-classe s'applique à l'extérieur.

Cela signifie que nous devrions ignorer le Sous-classe si la caractéristique de sous-classe n'est pas disponible dans outer :

Comme nous pouvons le voir maintenant, les deux, protected et package-private, sont au même niveau maintenant ( Y-Y-N ), plus de confusion sur la raison pour laquelle le niveau intermédiaire n'est pas autorisé. Dans l'ensemble, Java choisit uniquement package-private plutôt que protected pour éviter toute confusion ( c'est juste une question de choix mais protégé caractéristique principale est une sous-classe, donc package-private est supérieur), et l'option résultat Seuls deux modificateurs d'accès sont autorisés dans le niveau supérieur :

Au niveau supérieur - public, ou paquet - privé (sans modificateur explicite).