Pourquoi une classe à ne pas être défini comme protégé?

Parce qu'il n'a pas de sens.

Protégé membre de la classe (méthode ou variable) est juste comme colis-privé (visibilité par défaut), sauf qu'il peut également être consulté à partir de sous-classes.

Car il n'y a pas de notion comme "sous-paquetage" ou "paquet-héritage" à Java, la classe de déclaration protégée ou colis-privé serait la même chose.

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

public class A
{
    protected class B
    {
    }
}

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

Quatre modificateurs d'accès, supposons que le 1er niveau est public et 4ème niveau est privé (basé sur cette table dans la séquence). La première chose à savoir, c'est pourquoi la classe ne peut pas défini comme privé dans le haut niveau.

Si donc "privé de la classe foo"(Un membre privé défini, c'est à dire de la classe elle-même est membre) permettre, qu'est-ce que l'extérieur (qui contient le membre) ? De la portée du fichier ? Non, le fichier externe est inutile, parce que même plusieurs classes dans un seul fichier sera compiler pour séparer les fichiers de classe. Si l'extérieur est forfait. Mais le 3ème niveau par défaut modificateur d'accès signifie déjà "colis-privé". Donc le 4ème niveau de modificateur d'accès privé ne sera pas utilisé/autorisés.

Mais imbriquée privé de classe est de permettre parce que le direct externe est la classe, pas de paquet, par exemple:

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

Maintenant, si "protégés de la classe foo" autoriser ? protégé principale caractéristique est sous-classe, de sorte que le côté extérieur(package) DOIT(due à l'étendue, mais encore il est facultatif) fournir style de la sous-classe, c'est à dire sous-package, ou package A extends package B, mais nous ne connaissons pas de telle chose. Donc protégé ne pouvez pas utiliser le plein potentiel(champ d'application principal est la sous-classe-de large) dans le haut niveau dont l'extérieur est forfait(pas de sous-paquet de chose), mais protégé pouvez utiliser le plein potentiel dans la classe imbriquée dont l'extérieur est de classe(c'est à dire peut être sous-classe):

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

Noter que le dessus de ladite "ne peut pas utiliser le plein potentiel" en raison il ne peut pas atteindre la sous-classe à l'échelle simplement parce que dénuée de sous-classe, cela signifie réellement protégé peut être permettre, c'est juste une question de choix afin d'éviter de dupliquer le travail de colis-privé extérieur si pas de sous-classe-mesure, 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 de 1er niveau(public) et 3ème niveau (colis-privé), comment sur terre, dans l'entre-deux de 2e niveau (protégé) non autorisé ?

soutien public sous-classe si facile de les induire en erreur. La manière correcte de lecture de ce tableau est

soutien public sous-classe si l'extérieur a sous-classe de fonctionnalité.

La même trompeuse s'appliquent aux colis-privé, colis-privé ne prend pas en charge la sous-classe (N dans la cellule) ne signifie pas la sous-classe concept s'applique en extérieur.

Qui signifie que nous devrions ignorer les sous-classe colonne si la sous-classe fonctionnalité n'est pas disponible dans l':

Comme nous pouvons le voir maintenant, à la fois protégé et colis-privé sont au même niveau maintenant (Y-Y-N), plus de confusion au sujet de pourquoi-entre le niveau n'est pas autorisé. Dans l'ensemble, Java choisir seulement les colis-privé plus protégé pour éviter la confusion(c'est juste une question de choix, mais protégé principale caractéristique est sous-classe, afin de colis-privé est supérieur), et la résultat, à seulement 2 modificateurs d'accès a permis de haut niveau:

Au plus haut niveau du public, ou de colis-privé (explicite pas de modificateur).

comportement de “protégés” = le comportement “par défaut”+ “utiliser dans n'importe quelle sous-classe dans un paquet”.

De toute façon, nous avons modificateur d'accès par défaut pour la classe, le seul avantage que nous pouvons obtenir à partir protégés modificateur d'accès est:- en l'utilisant dans un paquet à travers le sous-classement. Mais pour la sous-classe, la visibilité de parent “protégés”de la classe serait privé. Donc il ne peut pas être consulté. En gros si vous avez un protégé de haut-niveau de la classe, ni extérieur de la classe peut accéder par le sous-classement. Donc protégé par un haut-niveau de la classe est vide de sens.

La réponse de @Akash5288 n'a pas de sens pour moi:

Si toutes les classes sont autorisés à sous-classe, puis il sera similaire à l'accès du public spécificateur.

Puisqu'il n'existe aucun moyen de restreindre cette classe d'être sous-classé par seulement quelques classes (on ne peut pas restreindre la classe héritée par seulement quelques classes, de toutes les classes disponibles dans un package/en dehors d'un paquet), il n'y a pas d'utilisation de protégé spécificateurs d'accès de haut niveau des classes. Par conséquent, il n'est pas permis.

Vous pouvez ensuite appliquer la même logique à protégées, des méthodes et des variables, ils sont alors "semblable à du public". Toutes les classes en dehors d'un paquet peut élargir notre public de la classe et de l'utilisation de ses protégés méthodes. Pourquoi restreindre les méthodes et les variables de l'étendue des classes ok, mais la restriction de l'ensemble de la classe n'est pas ok? "Semblable à du public" n'est pas "public". Mon interprétation est qu'il est parfaitement acceptable de permettre à une classe protégée, car elle est fine pour permettre protégé méthodes.

La réponse "vous ne pouvez pas étendre une classe que vous ne pouvez pas accéder à/voir" est plus logique.

protégé signifie que le membre ne peut être consulté par toutes les classes du même package
et en sous-classes, même s'ils sont dans un autre colis.

Exemple:

package a;
class parent{
 protected void p();
}
package b;
import a.p;
class child extends parent{
  //you can access method which is protected in the parent in the child 
}
class another extends child {
 //here you can not access the protected method 
}