Pourquoi une classe ne peut-elle pas être définie comme protégée?
Je sais que c’est une question stupide, mais j’ai encore un doute à éclaircir.
Ma question est, pourquoi ne pouvons-nous pas définir une classe comme protected?
Je sais que nous ne pouvons pas, mais pourquoi? Il devrait y avoir une raison spécifique.
Parce que ça n'a aucun sens.
Le membre de classe protégé (méthode ou variable) ressemble à package-private (visibilité par défaut), sauf qu'il est également accessible à partir de sous-classes.
Comme il n’existe pas de concept de «sous-paquet» ou «héritage de paquet» en Java, déclarer une classe protégée ou un paquet-privé serait la même chose.
Vous pouvez cependant déclarer les classes imbriquées et internes comme protégées ou privées.
Comme vous le savez, par défaut, l'accès est au niveau du paquet et protégé, au niveau du paquet et des classes non incluses dans le paquet, mais qui étend cette classe (à noter ici, vous pouvez étendre la classe uniquement si elle est visible!). Disons-le de cette façon:
- classe de niveau supérieur protégée serait visible pour 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-classe, ce sera similaire au spécificateur d'accès public.
- Si aucun n'est alors, il est similaire à default.
Puisqu'il n'y a aucun moyen de restreindre le sous-classement de cette classe par seulement quelques classes (nous ne pouvons pas restreindre l'héritage de classe par seulement quelques classes sur toutes les classes disponibles dans un package/en dehors d'un package), il n'est pas nécessaire d'utiliser des spécificateurs d'accès protégés. pour les cours de haut niveau. Par conséquent, ce 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 package ainsi qu'à l'extérieur du package par 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 l'entité dans laquelle cette classe est définie, qui est son paquet.
Et comme un paquet ne peut pas être étendu (peut être importé), définir une classe protégée le rendra à nouveau paquet-privé, ce qui revient à le définir comme valeur par défaut, ce que nous pouvons déjà faire . Par conséquent, il n’ya aucun avantage à définir un classe privée cela ne fera que rendre les choses ambiguës.
Pour plus d’informations, lisez Pourquoi une classe Java externe ne peut être ni privée ni protégée
Protégé n'est pas semblable au public. Protected a les deux accès de niveau paquet plus accessible en dehors des packages uniquement par héritage ... Si une classe dit A en dehors d'un package INHERITS a des méthodes protégées, mais les sous-classes dérivées de cette classe, c’est-à-dire, A ne peuvent pas accéder aux méthodes protégées. L’inverse se produit avec 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 «protected» = comportement de «default» + «utilisez-le dans n’importe quelle sous-classe de n’importe quel paquet».
Quoi qu’il en soit, nous avons le modificateur d’accès par défaut pour la classe, le seul avantage que nous pouvons tirer du modificateur d’accès protégé est: - en l’utilisant dans n’importe quel paquet via un sous-classement. Mais pour la sous-classe, la visibilité de la classe parent «protégée» serait privée. On ne peut donc pas y accéder. En gros, si vous avez une classe de niveau supérieur protégée, aucune classe externe ne peut y accéder en la classant en sous-classes. Donc, protégé pour une classe de haut niveau n'a pas de sens.
protected signifie que le membre est accessible à n'importe quelle classe du même package et à des sous-classes, même si elles se trouvent dans d'autres packages.
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
}
Ce qui a du sens pour cette question est que, JVM étant écrit en C (Sun JVM) et C++ (Oracle JVM), lors de la compilation, nous allons créer des fichiers .class à partir de notre fichier Java et si nous déclarons une classe avec le mot clé Protected JVM n’y aura alors pas accès.
La raison pour laquelle JVM n’a pas accès à la classe protégée, c’est que, puisque les champs protégés sont accessibles au sein du même package ou d’un package à l’autre par héritage, la JVM n’est pas écrite de manière à hériter de la classe. J'espère que cela répond à cette question :)
De même, une classe de niveau supérieur ne peut pas être privée. Explication 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 paquet?
Donc, définir un 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. Par conséquent, il n'y a aucun avantage à définir une classe privée, cela ne fera que rendre les choses ambiguës.
La réponse de @ Akash5288 n'avait aucun sens pour moi:
Si toutes les classes sont autorisées à sous-classe, ce sera similaire au spécificateur d'accès public.
Puisqu'il n'y a aucun moyen de restreindre le sous-classement de cette classe par seulement quelques classes (nous ne pouvons pas restreindre l'héritage de classe par seulement quelques classes sur toutes les classes disponibles dans un package/en dehors d'un package), il n'est pas nécessaire d'utiliser des spécificateurs d'accès protégés pour les cours de haut niveau. Par conséquent, ce n'est pas permis.
Vous pouvez ensuite appliquer la même logique à des méthodes et à des 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 restreindre les méthodes et les variables aux classes étendues est-il correct, mais ne pas restreindre la classe entière? "Similaire au public" n'est pas "identique au public". Mon interprétation est qu’il est parfaitement correct d’autoriser une classe protégée, tout comme d’autoriser les méthodes protégées.
La réponse "vous ne pouvez pas étendre une classe à laquelle vous ne pouvez pas accéder/voir" est plus logique.
Protected : VISIBLE uniquement au niveau du package *.
la classe est définie protected---> it ne peut pas être étendue depuis un paquet extérieur (non visible).
Et s'il ne peut pas être étendu, il est inutile de le conserver en tant que protected, car il deviendra alors l'accès default autorisé.
Il en va de même pour les classes définies par private.
Remarque: Les classes imbriquées ou internes peuvent être définies protected ou private.
* : Mot clé Explore protected, pour cette réponse, je l'ai fait succinct.