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

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

• la classe de niveau supérieur protégée serait visible par les classes de son package.
• maintenant, le rendre visible en dehors du paquet (sous-classes) est un peu déroutant et délicat. Quelles classes devraient être autorisées à hériter de notre classe protégée?
• Si toutes les classes sont autorisées à sous-classer, il sera similaire au spécificateur d'accès public.
• Si none alors il est similaire à default.

Comme il n'y a aucun moyen de restreindre cette classe à quelques classes seulement (nous ne pouvons pas restreindre la classe à quelques classes seulement parmi toutes les classes disponibles dans un paquet/en dehors d'un paquet), il n'y a pas d'utilisation de spécificateurs d'accès protégés pour les classes de niveau supérieur. Par conséquent, il n'est pas permis.

public class A
{
    protected class B
    {
    }
}

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

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

Et puisqu'un paquet ne peut pas être étendu (peut être importé), définir une classe protégée le rendra à nouveau package-private, ce qui est similaire à la définition par défaut, ce que nous pouvons déjà faire. Par conséquent, il n'y a aucun avantage à définir une classe privée, 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

Sur les 4 modificateurs d'accès "public, private, protected et default", une classe ne peut avoir que public et default modifier.

Si vous avez une classe publique, vous pouvez l'utiliser où vous voulez, ce qui est très simple. Vous pouvez l'importer dans un paquet et commencer à l'utiliser.

Mais, si vous avez une classe sans modificateur/par défaut, vous ne pouvez même pas l'importer dans un autre package. Par exemple, vous avez la classe:as DefaultClass.java

package home;
class DefaultClass{
..
}

Et une autre classe comme TestingIt.java dans un autre paquet.

package office;
import home.

Le moment où vous essayez d'importer la maison.DefaultClass dans le code ci-dessus, vous vous rendrez compte que notre DefaultClass ne peut pas être importé. Il n'est pas visible pour un paquet à l'extérieur de la maison. Nous ne pouvons pas l'importer dans ce TestingIt.fichier java. Pourquoi pas? parce que default = limité à son propre package.

Et maintenant à votre question " pourquoi une classe ne peut pas avoir un modificateur d'accès protégé?" Je pense que c'est probablement parce que ce ne serait pas différent d'un défaut / non modificateur de classe. Même si "classe protégée "était possible, vous ne seriez pas en mesure de l'importer dans un autre package tout comme une"classe de modificateur par défaut/sans".

Vous pouvez les utiliser dans le même paquet, mais une fois que vous les importez, les deux fonctionneraient exactement de la même manière dans le même paquet. Par conséquent, en ce qui concerne les modificateurs d'accès pour les classes, protected et default sont les mêmes.

@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 je pensais et maintenant je devrais complètement comprendre 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 que nous devrions savoir est pourquoi la classe ne peut pas être définie comme privée au niveau supérieur.

Donc si "classe privée foo" (Un membre privé défini, c'est-à-dire que la classe elle-même est un membre) autoriser, quel est l'extérieur (qui contient le membre) ? Portée du fichier ? Non, file outer 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{[13] } est autorisée car le direct extérieure 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, que se passe-t-il si "protected class foo" le permet ? la caractéristique principale protégée est une sous-classe, donc le(paquet) externe DEVRAIT(en raison de la portée maximale, mais toujours facultatif) fournir style de sous-classe, c'est-à-dire un sous-paquet, ou 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) au niveau supérieur dont l'extérieur est un package(c'est-à-dire pas de sous-package), mais protected peut utiliser 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!");
        }
    }
}

Notez que ce qui précède dit "ne peut pas utiliser le plein potentiel" car il ne peut pas atteindre l'ensemble de la sous-classe simplement parce qu'aucune sous-classe externe, cela signifie que réellement protégé peut être autorisé, c'est juste une question de choix pour éviter de dupliquer le travail de package-private if outer not subclassable, 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 3e niveau (paquet-privé) sont autorisés, comment diable le 2e niveau intermédiaire (protégé) n'est pas autorisé ?

Sous-classe de soutien public si facile à induire en erreur. La bonne façon de lire ce tableau est

Public support subclass si l'externe a une fonctionnalité de sous-classe.

La même erreur s'applique à pacakage-private, pacakage-private ne prend pas en charge la sous-classe (N dans la cellule) ne signifie pas que le concept de sous-classe s'applique en externe.

Cela signifie que nous devrions ignorer la colonne Subclass si la fonctionnalité de sous-classe n'est pas disponible dans outer:

Comme nous pouvons le voir maintenant, protected et package-private sont maintenant le même niveau ( Y-Y-N), plus de confusion sur les raisons pour lesquelles le niveau intermédiaire n'est pas autorisé. Dans l'ensemble, Java ne choisit que le package-privé sur protégé pour éviter confusing ( c'est juste une question de choix , mais protected la caractéristique principaleest une sous-classe, donc package-private est supérieur), et le result, seulement 2 modificateurs d'accès autorisés au niveau supérieur:

Au niveau supérieur-public, ou package-private (pas de modificateur explicite).

Protected n'est pas similaire à public. Protected a à la fois un accès au niveau du paquet et peut être consulté en dehors des paquets uniquement par héritage..Si une classe dit A en dehors d'un paquet HÉRITE d'une classe d'un autre paquet(avec une méthode protégée en utilisant l'HÉRITAGE), elle peut accéder aux méthodes de cette classe B qui a des méthodes protégées mais les sous-classes dérivées de cette classe, c'est-à-dire A ne peut pas accéder aux méthodes protégées..le contraire se produit avec le public..

Exemple:

package 2;
class B
{
protected void method1()
{
}
}
package 1;
import 2.B;
class A extends B
{
//can access protected method
}
class C extends A
{
//can't access the protected method
}

Comportement de "protégés" = le comportement "par défaut"+ "utiliser dans n'importe quelle sous-classe dans un package".

Quoi qu'il en soit, nous avons un modificateur d'accès par défaut pour la classe, le seul avantage que nous pouvons obtenir du modificateur d'accès protégé est:- en l'utilisant dans n'importe quel package via un sous-classement. Mais pour la sous-classe, la visibilité de la classe parent "protégée"serait privée. Donc il ne peut pas être consulté. Fondamentalement, si vous avez une classe de niveau supérieur protégée, aucune classe externe ne peut y accéder en la sous-classant. Donc protégé pour un niveau supérieur la classe est vide de sens.

Protected: VISIBLE uniquement au niveau du paquet*.

Est définie protégée ---> il ne peut pas être étendu depuis un paquet extérieur(non visible).

Et s'il ne peut pas être étendu, il n'a aucun sens de le garder comme protégé, car alors il deviendra accès par défaut qui est autorisé.

Il en va de même pour les classes définies privées.

Remarque: Les classes imbriquées ou internes peuvent être définies protégé ou private.

* : Explorer mot-clé protégé , pour cette réponse, je l'ai rendue succincte.

La réponse de @ Akash5288 n'avait aucun sens pour moi:

Si toutes les classes sont autorisées à sous-classer, il sera similaire au spécificateur d'accès public.

Comme il n'y a aucun moyen de restreindre cette classe à quelques classes seulement (nous ne pouvons pas restreindre la classe à quelques classes seulement parmi toutes les classes disponibles dans un paquet/en dehors d'un paquet), il n'y a pas d'utilisation de spécificateurs d'accès protégés pour les classes de niveau supérieur. Par conséquent, il n'est pas permettre.

Vous pouvez ensuite appliquer la même logique aux méthodes et variables protégées, elles sont également "similaires à public". Toutes les classes en dehors d'un paquet peuvent étendre notre classe publique et utiliser ses méthodes protégées. Pourquoi la restriction des méthodes et des variables aux classes étendues est-elle ok, mais la restriction de la classe entière n'est pas ok? "Semblable à du public" n'est pas "public". Mon interprétation est qu'il est parfaitement correct d'autoriser une classe protégée, comme il est bon d'autoriser protected méthode.

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

Ce qui a du sens à cette question, c'est que JVM est écrit en C (Sun JVM) et C++(oracle JVM) donc pendant la compilation, nous allons créer .fichiers de classe hors de notre fichier java et si nous déclarons une classe avec un mot clé protégé, il ne sera pas accessible par JVM.

La réponse pourquoi la classe protégée ne sera pas accessible par la JVM est que, puisque les champs protégés sont accessibles dans le même paquet ou à un paquet différent via l'héritage uniquement et que la JVM n'est pas écrite de manière à ce qu'elle héritera de la classe will. J'espère que cela satisfait cette question:)

De même, une classe de niveau supérieur ne peut pas être privée. Explication comme ci-dessous:

Alors que se passera - t-il si nous définissons une classe privée, cette classe ne sera accessible que dans l'entité dans laquelle elle est définie qui dans notre cas est son package?

Ainsi, définir l'accès privé à la classe le rendra accessible dans le même package que le mot-clé par défaut le fait déjà pour nous, il n'y a donc aucun avantage de définir une classe privée ne fera que rendre les choses ambiguës.

protected means that the member can be accessed by any class in the same package 
and by sub classes even if they are in another packages.
example:
    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 
    }