Quelle est la raison pour laquelle, en Java, un membre avec un modificateur "protected" peut non seulement être accédé par la même classe et par les sous-classes, mais aussi par tous les membres du même paquetage ?
Je m'interroge sur les raisons de la conception du langage, et non sur les applications réelles (par exemple, les tests).
Les modificateurs sont bien décrits sur http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html . De là, nous voyons cette figure.
Modifier Class Package Subclass World
public Y Y Y Y
protected Y Y Y N
no modifier Y Y N N
private Y N N NLa raison de cette décision de conception est évidente : il s'agit d'avoir une belle matrice symétrique.
@Michael Myers : Eh bien, non, ce ne serait pas symétrique de toute façon. C'est symétrique pour une raison.
Si vous mettez un N au lieu d'un Y à l' protected -> intersection des paquets, c'est toujours symétrique. Mais pas aussi jolie.
Dans Java 1.0, il y avait un cinquième modificateur d'accès : private protected . C'était protected sans l'accès par défaut. Apparemment, cela n'a jamais fonctionné correctement et a été abandonné dans la version 1.1. Donc il semble que les réclamations protected est définie de la manière dont elle l'est pour que les commandes totales semblent être fausses. ( Editar: Il semble bien qu'au moins une des raisons pour lesquelles le cinquième modificateur d'accès a été supprimé dans la version 1.1 était que l'absence d'ordre total interférait avec les règles de sélection des surcharges). Le site module Le modificateur d'accès dans Java 7 pose quelques questions de conception dans ce domaine.
Étant donné que l'on a pensé que ce serait une bonne idée que le modificateur d'accès par défaut pour les membres soit "package private", il semble raisonnable que protected devrait avoir au moins ce niveau d'accès. Pour mon argent, protected ne fait pas du tout son chemin dans la langue.
Et comme personne ne vous empêche d'ajouter d'autres classes à un paquet dans un fichier jar différent, "package private" n'est pas si privé que cela non plus. C'est ainsi : Tout ce qui est en dehors de private et public est plus ou moins une indication pour le programmeur mais pas une réelle protection.
Une question très tardive, mais avez-vous une source à ce sujet ? J'aimerais savoir plus en détail comment et pourquoi cela a échoué à l'époque.
En gros, cela a à voir avec la vision d'un paquet comme une unité contrôlée par l'API (d'où la recommandation de commencer votre paquet avec votre nom de domaine - unicité globale garantie), donc la visibilité augmente de privé -> paquet-privé -> protégé -> public. Si protected n'était pas une augmentation par rapport à package-private, mais plutôt un type de visibilité différent, il devrait y avoir un moyen de combiner les deux types de visibilité en cas de besoin.
Mais personne ne vous empêche d'ajouter une nouvelle classe à un paquet déjà existant. Donc "package private" et avec lui "protected" n'est qu'une recommandation pour les programmeurs. Les deux n'offrent aucune protection réelle contre les programmeurs malveillants/espérés qui veulent/doivent appeler la méthode. - Le terme "protected", comme en C++, obligerait au moins à utiliser une sous-classe, mais en Java, ce n'est même pas nécessaire.
Étant donné les niveaux progressifs d'accès, private, package, protected et public, il serait inutilement restrictif de choisir protected puis package, car cela m'obligerait à autoriser l'accès aux sous-classes afin d'accorder l'accès aux autres membres du même package. Pourtant, intuitivement, il devrait être que les autres classes du même paquet sont plus fiables que les autres classes "à l'extérieur". Ainsi, protected se situe entre package et public dans la mesure où il permet une plus grande exposition de l'accès.
Je pense que la raison fondamentale repose sur l'intuition qu'il existe un niveau de "confiance" de base entre les classes d'un même paquet ; on peut raisonnablement s'attendre à ce qu'elles fassent la bonne chose entre elles - dans la plupart des cas, le paquet sera la responsabilité d'un seul ingénieur ou d'une seule équipe, il devrait donc y avoir une harmonie cohérente dans la conception.
C'est la théorie. Mais dans la pratique, cela ne serait vrai que si un paquet devait être compilé dans une seule unité de compilation et ne pouvait pas être amélioré en dehors. Mais ce n'est pas le cas et donc, à l'aide d'une classe de délégué mince, toute méthode "package private" peut être rendue publique. Une indication pour le programmeur mais pas une véritable protection.
@martin : seulement si vous publiez le paquet sans le sceller, ce qui permet de résoudre ce problème particulier.
"sceller le paquet" - je n'en ai jamais entendu parler mais cela semble intéressant. Dites-moi en plus ! (quelques mots pour m'aider à googler les détails c'est suffisant)
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
12 votes
+1 Franchement, je veux aussi savoir pourquoi. Cela m'a toujours paru être l'une des décisions de conception les plus stupides de Java.
3 votes
@cletus : Plus j'y pense, plus j'en arrive à la conclusion que le "paquet privé" n'était pas une idée bien pensée. Pour que "package private" fonctionne réellement et offre une protection réelle, les paquets devraient être compilés dans une seule unité de compilation. Et il ne devrait pas être possible de les améliorer ultérieurement.