La réflexion est-elle un inconvénient car les variables privées ne peuvent pas être restreintes?

Le privatemodificateur est utilisé pour restreindre l'accès en dehors de la classe, mais en utilisant la réflexion, d'autres classes peuvent accéder à des méthodes et des champs privés. Je me demande donc comment nous pouvons restreindre l'accessibilité si cela fait partie des exigences.

Le but des modificateurs d'accès est d'informer les développeurs qui écrivent du code sur ce qu'est l'interface publique d'une classe. Ils ne sont en aucun cas une mesure de sécurité et ils ne cachent ni ne sécurisent aucune information.

Pour citer Herb Sutter sur les droits d'accès aux cours :

"La question ici est de se protéger contre Murphy contre se protéger contre Machiavel ... c'est-à-dire, se protéger contre les abus accidentels (ce que le langage fait très bien) contre se protéger contre les abus délibérés (ce qui est effectivement impossible). En fin de compte, si un programmeur veut assez pour renverser le système, il trouvera un moyen "

Non, c'est en fait un avantage important. Tout simplement parce que certains développeurs ne considéraient pas que quiconque aurait besoin d'accéder à un élément d'état interne ne signifie pas qu'aucun cas d'utilisation légitime ne se présenterait jamais. Dans ces cas, l'utilisation de la réflexion pour effectuer une intervention chirurgicale sur un objet peut être un dernier recours. J'ai dû utiliser cette technique plus d'une fois.

Vous restreignez encore plus l'accessibilité en remontant d'un niveau: l'environnement d'exécution.

Tous les langages n'ont pas ce concept, mais au moins avec Java, vous pouvez utiliser un gestionnaire de sécurité qui interdit de rendre les champs privés accessibles. Vous pouvez installer manuellement le gestionnaire de sécurité au moment de l'exécution ou ajouter une politique de sécurité dans un fichier jar qui est ensuite scellé pour empêcher toute modification.

Plus d'informations sur cette opération en Java: Reflection Security

De quelle réflexion parlez-vous?

Dans de nombreux systèmes de réflexion, le contournement de l'encapsulation est une capacité explicite que votre code doit obtenir, et n'a pas par défaut.

Si vous êtes préoccupé par l'encapsulation, la solution simple est simplement de ne pas utiliser un système de réflexion qui ne le préserve pas.

En Python, il n'y a pas de modificateurs d'accès. La convention consiste à préfixer par un trait de soulignement les méthodes et les variables qui ne devraient pas être accessibles depuis l'extérieur de la classe. Est-ce que cela vous empêche techniquement d'accéder à ce champ à partir d'une classe tierce? Pas du tout; mais si vous le faites, vous êtes seul et vous prenez le risque de casser quelque chose, sans pouvoir blâmer l'autre classe.

En C #, les modificateurs d'accès existent, mais ils ne sont encore qu'une convention - celle qui est appliquée par un compilateur, mais toujours une convention. Cela signifie que techniquement, on peut toujours accéder et modifier des variables privées, soit par le biais de Reflection, soit en altérant directement la mémoire (comme le font les entraîneurs de jeux ). La conséquence est exactement la même: si les variables de votre classe sont modifiées par la réflexion d'une autre classe, ou par l'altération de la mémoire par une autre application, et que cela casse quelque chose dans votre classe, ce n'est pas votre faute.

Notez que cela, évidemment, crée des problèmes de sécurité où un tiers peut accéder à vos données; quelque chose qui conduit à des variantes cryptées d'une chaîne et à des structures de données similaires. Mais la protection de votre code contre une telle utilisation est davantage liée aux restrictions d'accès au niveau du système d'exploitation et du code , et n'a rien à voir avec Reflection en soi.