92 votes

Méthodes privées sont vraiment sûrs ?

En Java, l' private modificateur d'accès considérer comme sûr, car il n'est pas visible à l'extérieur de la classe. Ensuite, le monde extérieur ne connais pas cette méthode.

Mais j'ai pensé réflexion Java peuvent utiliser pour briser cette règle. Considérons le cas suivant:

public class ProtectedPrivacy{

  private String getInfo(){
     return "confidential"; 
  }

}  

Désormais, à partir d'une autre classe, je vais obtenir des informations:

public class BreakPrivacy{

   public static void main(String[] args) throws Exception {
       ProtectedPrivacy protectedPrivacy = new ProtectedPrivacy();
       Method method = protectedPrivacy.getClass().getDeclaredMethod("getInfo", null);
       method.setAccessible(true);
       Object result = method.invoke(protectedPrivacy);
       System.out.println(result.toString());
   }
} 

En ce moment, j'ai juste pensé encore privés méthode sûre depuis de faire quelque chose comme ci-dessus, il nous faut connaître le nom de la méthode. Mais si la classe qui contient méthode privée écrite par quelqu'un d'autre nous n'avons pas de visibilité de ceux-ci.

Mais de mon point de devenir invalide depuis dessous de la ligne de code.

Method method[] = new ProtectedPrivacy().getClass().getDeclaredMethods();

Maintenant, c' method[] contient toutes les choses à faire au-dessus de chose. Ma question est, est-il un moyen pour éviter ce genre de choses à faire à l'aide de Java réflexion?

Je suis en citer quelques-point de la Documentation Java pour préciser ma question.

Conseils sur le Choix d'un Niveau d'Accès:

Si d'autres programmeurs d'utiliser votre classe, vous voulez vous assurer que les erreurs d'une mauvaise utilisation ne peut pas se produire. Niveaux d'accès peuvent vous aider à le faire.L'utilisation de la plus restrictif niveau d'accès qui fait sens pour un particulier membre. Usage privé, sauf si vous avez une bonne raison de ne pas.

95voto

Jon Skeet Points 692016

Cela dépend de ce que tu veux dire par "sans danger". Si vous êtes en cours d'exécution avec un responsable de la sécurité qui permet ce genre de chose, alors oui, vous pouvez faire toutes sortes de choses désagréables avec la réflexion. Mais alors dans ce genre d'environnement de la bibliothèque peut probablement juste être modifié afin de rendre la méthode public de toute façon.

Le contrôle d'accès est effectivement "consultatif" dans un environnement comme celui - la, vous êtes effectivement de faire confiance au code pour jouer bien. Si vous n'avez pas confiance le code que vous êtes en cours d'exécution, vous devez utiliser un plus restrictive gestionnaire de sécurité.

40voto

jmoreno Points 6995

Modificateurs d'accès n'ont rien à voir avec la sécurité. En fait, vous pouvez et devriez regarder les modificateurs d'accès comme l'inverse de la sécurité, il n'est pas de protéger vos données ou algorithims, c'est de protéger les personnes de l'obligation de communiquer vos données et algorithims. C'est pourquoi la modification par défaut est tout, si ils travaillent sur le paquet ils ont probablement déjà devez savoir.

Avec la connaissance des données et les méthodes de votre code, vient la responsabilité de savoir quand et comment l'utiliser. Vous ne mettez pas de privé sur votre méthode inIt de garder quelqu'un de trouver à ce sujet, vous le faites parce que (a) ils ne vont pas savoir que vous appelez seulement qu'après foo et seulement si la barre = 3.1415 et (b) parce qu'il ne fait pas bon de savoir à ce sujet.

L'accès modiers peut se résumer en une phrase simple "TMI, mec, j'ai donc n'a pas besoin de savoir que".

7voto

Arsen Alexanyan Points 1370

En disant « sûrs », vous protégez vous ou les autres développeurs, qui utilisent votre API pour ne pas nuire à l’objet en appelant votre méthode privée. Mais si vous, ou qu’ils ont vraiment besoin d’appeler cette méthode, ils peuvent le faire avec la réflexion.

6voto

Nishant Shreshth Points 5675

La question est de savoir qui sont que vous essayez d' enregistrer à partir de. À mon avis, un tel client de votre code est celui à perte ici.

Tout morceau de code (écrit par vous ou d'autres), qui tente d'accéder à un private membre de la classe ci-dessus est essentiellement de creuser sa propre tombe. private des membres ne font pas partie du public de l'API et sont sujets à changement sans préavis. Si un client arrive de consommer de l'un de ces membres privés de la manière présentée ci-dessus, il va se casser si il se met à jour vers une version plus récente de l'API dans laquelle le membre privé a modifié.

5voto

Raúl Points 211

Avec facilité, il vient la responsabilité. Il y a des chose que vous ne pouvez pas faire, et des choses que vous pouvez faire, mais vous ne devriez pas le faire.

Privé modificateur est fournie ou utilisée comme/le plus restreint. Les membres qui ne doivent pas être visibles de l'extérieur de la classe doit être définie comme privée. Mais cela peut être rompu avec la Réflexion que nous voyons. Mais cela ne signifie pas que vous ne devriez pas utiliser ou privé, ils sont dangereux. C'est à propos de l'utilisation de choses judicieusement ou de façon constructive (comme réflexion).

Prograide.com

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.

Powered by:

X