Méthodes privées utilisant la réflexion .NET. Pourquoi?

Question

J’ai déjà utilisé de nombreuses fois la réflexion sur des méthodes publiques, mais je n’ai jamais réalisé que les méthodes privées pouvaient aussi être invoquées. Voir Réflexion avec des membres privés . . . p>

Pourquoi est-ce permis en premier lieu? Cela ne va-t-il pas enfreindre la règle de "privé"? être "privé"?

Answer 1

private en C # n'est vraiment qu'une partie de la spécification du langage; dans le langage C #, ainsi que dans le langage Visual Basic ou dans tout autre langage sensible .NET (y compris CIL , ce que tous les langages .NET compilent) empêche l’accès à private (ou protected , si vous ne faites pas partie d’une classe dérivée) member < strong> dans la langue . Cependant, le fait que la langue ne prenne pas en charge l'accès public aux membres private ou protected ne signifie pas que le framework sous-jacent ne permet pas d'accéder à ces membres.

C’est l’un des cas où ne devrait pas utiliser des solutions de contournement telles que la réflexion pour accéder à ou modifier des membres privés ou protégés , mais le cadre permet quand même. En règle générale, vous devez disposer d'une très très bonne raison pour accéder aux membres privés ou protégés ; L'une de ces raisons, par exemple, est la mise en œuvre d'un sérialiseur qui doit examiner l'état interne de l'objet pour le sérialiser correctement. Si vous ne faites pas quelque chose comme ça, vous devriez vraiment envisager de réimplémenter la classe dans laquelle vous fouillez, afin que vous n'ayez pas besoin d'utiliser la réflexion dans votre programme.

Answer 2

Ceci n'est autorisé que lorsque le code s'exécute sous une confiance totale (ou avec l'autorisation appropriée). Sinon, une MethodAccessException sera levée.

Le framework est parfaitement capable de restreindre l'accès de manière appropriée. Il ne le fait tout simplement pas lorsque vous travaillez en toute confiance ou lorsque vous disposez d'autorisations spécifiques. Consultez "Considérations sur la sécurité pour Reflection" pour plus de détails sur le moment êtes capable de faire cela.

Answer 3

Oui, cela enfreint la règle. Je ne passerais presque jamais le code lors d'un examen si quelqu'un le faisait.

L’utilisation de la réflexion pour appeler une méthode est slllloooow, elle n’est pas sécurisée contre les types et elle se brise facilement si la classe sous-jacente a retravaillé les méthodes privées.

En bref, je suis d’accord, c’est une mauvaise idée!

Answer 4

C’est le pouvoir avancé que vous obtenez du framework. Il est très rare de l’utiliser dans le code de production pour invoquer des méthodes, cela rompt les avantages de la dissimulation des membres.

Cela peut être utile à certains endroits:

• Test du code hérité : par exemple, supposez que vous travaillez avec du code hérité et que vous souhaitez le couvrir avec des tests unitaires. Si vous n’êtes pas autorisé à modifier le code et que vous souhaitez tester une petite partie de la fonctionnalité, l’appel de méthodes privées est utile.
• Hacks dans le code de production : j'ai rencontré un bogue dans le contrôle par une tierce partie qui, dans certains cas, ne permettait pas de nettoyage privé. En utilisant invoke, je pourrais contourner le problème.

Il n’ya rien de mal à ce que le framework fournisse cette fonctionnalité, mais l’utiliser là où ce n’est pas indispensable est mauvais.

Answer 5

Reflection est une fonctionnalité puissante de .NET, mais a aussi ses inconvénients.

Avantages:

1. Reflection permet d'accéder à tous les membres (y compris les membres privés et protégés), à condition que vous disposiez au moins de la sécurité ReflectionPermission . (Cette autorisation peut être obtenue lorsque votre application accède à l'assemblage réfléchi à partir du même lecteur, et non d'Internet.)

2. Dans de rares cas, la réflexion est le seul moyen d'effectuer une tâche.

Inconvénients:

1. La réflexion rompt la sécurité (tout comme la décompilation d'un assemblage). Pour obtenir une sécurité complète sur le code et les données de votre application, vous devez utiliser la cryptographie et non pas simplement vous fier aux mots clés Private ou Protected, car, seuls, ils peuvent facilement être interrompus par réflexion ou décompilation.

2. La réflexion est beaucoup plus lente et consomme plus de ressources que le référencement statique (comme vous appelez des méthodes). Pour cette raison, évitez toute réflexion, à moins que ce soit le seul moyen de résoudre votre problème.

Des exemples illustrant les cas où la réflexion est le seul moyen de résoudre le problème sont les suivants:

1. Supposons que votre application compile le code de manière dynamique (par exemple, lorsque vous tracez les fonctions que l'utilisateur fournit au moment de l'exécution). Dans ce cas, la réflexion est le seul moyen de charger les assemblys et les types.

2. Vous voulez cloner un objet. Vous devez utiliser la réflexion pour accéder à ses champs privés.

J'espère que cela aide. Je voudrais remercier ici M. Francesco Balena pour son bel ouvrage, Programming Microsoft Visual Basic 2005: The Language.