2009-11-28 7 views

Répondre

3

private en C# est vraiment seulement une partie de la spécification du langage; dans le langage C#, ainsi que dans le langage Visual Basic ou tout autre langage .NET sensible (y compris CIL, ce que tous les langages .NET compilent) est empêché d'accéder à un private (ou protected, si vous n'êtes pas dans une classe dérivée) membre dans le langage. Toutefois, le fait que le langage ne prenne pas en charge l'accès public aux membres private ou protected ne signifie pas que le cadre sous-jacent ne peut pas fournir l'accès à ces membres.

C'est l'un de ces cas où l'on ne doit pas en général être en utilisant des solutions de contournement comme réflexion pour accéder ou modifier private ou protected membres, mais le cadre permet une toute façon. Généralement, vous devriez avoir un très bonne raison d'accéder aux membres private ou protected; L'une de ces raisons est, par exemple, l'implémentation d'un sérialiseur qui doit examiner l'état interne de l'objet pour correctement sérialiser l'objet. Si vous ne faites pas quelque chose comme ça, vous devriez vraiment essayer de réimplémenter la classe dans laquelle vous vous trouvez, de sorte que vous n'ayez pas besoin d'utiliser la réflexion dans votre programme.

1

Oui, cela enfreint la règle. Je n'aurais presque jamais passer de code lors d'un examen si quelqu'un l'a fait.

L'utilisation de la réflexion pour appeler une méthode est correcte, non sécurisée et se casse facilement si la méthode sous-jacente a des méthodes privées retravaillées.

Donc, en bref, je suis d'accord, c'est une mauvaise idée!

+0

étrange. pourquoi ils permettaient cela ... tout à coup, le monde n'est plus en sécurité;) –

1

Ceci est une puissance avancée que vous obtenez de la structure. Il est très rare de l'utiliser dans le code de production pour invoquer des méthodes, cela brise les avantages des membres qui se cachent.

Il y a des endroits où il peut être utile:

  • test de code Legacy - Par exemple, supposons que vous travaillez avec le code existant et que vous voulez 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é, invoquer des méthodes privées est utile.
  • Hacks dans le code de production - J'ai rencontré une fois un bug dans le contrôle tiers où, dans certains cas, un nettoyage privé n'a pas été fait. En utilisant l'invocation privée, je pourrais contourner ce problème.

Il n'y a rien de mal avec le cadre offrant cette fonctionnalité, mais l'utiliser là où ce n'est pas un must est faux.

3

Ceci n'est autorisé que lorsque le code est exécuté en toute confiance (ou avec l'autorisation correspondante). Sinon, un MethodAccessException sera lancé.

Le framework est parfaitement capable de restreindre l'accès de manière appropriée - il ne le fait pas lorsque vous utilisez une confiance totale ou lorsque vous avez des autorisations spécifiques. Voir "Security Considerations for Reflection" pour plus de détails quand vous êtes capable de le faire.

1

La réflexion est une fonctionnalité puissante dans .NET mais a aussi ses inconvénients.

Plus:

  1. permet de réflexion un accès à tous les membres (y compris le secteur privé et protégé), à condition que vous avez au moins la ReflectionPermission sécurité. (Cette autorisation peut être obtenue lorsque votre application accède à l'assembly reflété à partir du même lecteur, et non à partir d'Internet.)

  2. Dans certains cas rares, la réflexion est la seule manière d'effectuer une tâche.

Moins:

  1. Réflexion sécurité pauses (comme le fait décompiler un ensemble). Pour obtenir une sécurité complète sur le code et les données de votre application, vous devez utiliser la cryptographie, et ne pas vous fier uniquement aux mots clés privés ou protégés, car ils peuvent être facilement interrompus par la réflexion ou la décompilation.

  2. La réflexion est beaucoup plus lente et consomme plus de ressources que le référencement statique (la méthode normale d'appel des méthodes). Pour cette raison, vous devriez éviter la réflexion à moins que ce soit la seule façon de résoudre votre problème.

Exemples quand la réflexion est la seule façon de résoudre le suivi du problème:

  1. Supposons que votre application compile dynamiquement le code (par exemple lorsque vous tracer des fonctions que l'utilisateur fournit à run-time). Dans de tels cas, le seul moyen de charger les assemblages et les types est la réflexion.

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

J'espère que cela aide. Je devrais remercier ici M. Francesco Balena pour son beau livre, Programmation Microsoft Visual Basic 2005: The Language.