3

以前はパブリック メソッドでリフレクションを何度も使用していましたが、プライベート メソッドも呼び出すことができることに気づきませんでした。プライベート メンバーでのリフレクションを参照してください。

そもそもなんで許されるの？それは「プライベート」が「プライベート」であるというルールを破ることになりませんか？

4

5 に答える 5

4

これは、コードが完全な信頼の下で (または関連するアクセス許可で) 実行されている場合にのみ許可されます。それ以外の場合は、 aMethodAccessExceptionがスローされます。

このフレームワークは、アクセスを適切に制限することができます。完全な信頼の下で実行している場合や、特定のアクセス許可を持っている場合は制限できません。これが可能な場合の詳細については、「リフレクションのセキュリティに関する考慮事項」を参照してください。

于 2009-11-28T07:52:21.420 に答える
4

privatein C# は本当に言語仕様の一部にすぎません。C# 言語だけでなく、Visual Basic 言語またはその他の実用的な .NET 言語 (すべての .NET 言語がコンパイルするCILprivateを含む) では、 (またはprotected、派生言語内にない場合は ) にアクセスできません。 class)言語のメンバー。ただし、言語がパブリック アクセスprivateまたはprotectedメンバーをサポートしていないからといって、基になるフレームワークがそれらのメンバーへのアクセスを提供できないわけではありません。

これは、通常、リフレクションなどの回避策を使用してメンバーにアクセスまたは変更するべきではないケースの 1 つですが、フレームワークではとにかく許可されています。一般に、またはメンバーにアクセスするには十分な理由が必要です。たとえば、そのような理由の 1 つは、オブジェクトを適切にシリアル化するためにオブジェクトの内部状態を確認する必要があるシリアライザーを実装することです。そのようなことをしていない場合は、プログラムでリフレクションを使用する必要がないように、内部をいじっているクラスを再実装することを真剣に検討する必要があります。privateprotectedprivateprotected

于 2009-11-28T06:28:35.567 に答える
1

リフレクションは .NET の強力な機能ですが、短所もあります。

長所：

  1. Reflection は、少なくともReflectionPermissionセキュリティがあれば、すべてのメンバー (プライベートおよび保護されたメンバーを含む) へのアクセスを許可します。(このアクセス許可は、アプリケーションがインターネットからではなく、同じドライブから反映されたアセンブリにアクセスするときに取得できます。)

  2. まれに、リフレクションがタスクを実行する唯一の方法である場合があります。

短所：

  1. リフレクションはセキュリティを破ります (アセンブリの逆コンパイルと同様)。アプリケーションのコードとデータに対して完全なセキュリティを確保するには、Private または Protected キーワードだけに依存するのではなく、暗号化を使用する必要があります。

  2. リフレクションは、静的参照 (メソッドを呼び出す通常の方法) よりもはるかに遅く、より多くのリソースを消費します。このため、問題を解決する唯一の方法でない限り、リフレクションを避ける必要があります。

リフレクションが問題を解決する唯一の方法である場合の例を次に示します。

  1. アプリケーションがコードを動的にコンパイルするとします (ユーザーが実行時に提供する関数をプロットする場合など)。このような場合、アセンブリと型を読み込む唯一の方法は、リフレクションを使用することです。

  2. オブジェクトのクローンを作成します。プライベート フィールドにアクセスするには、リフレクションを使用する必要があります。

これが役立つことを願っています。ここで、Francesco Balena 氏のすばらしい本、Programming Microsoft Visual Basic 2005: The Language に感謝しなければなりません。

于 2012-07-06T13:59:14.307 に答える
1

ええ、それはルールを破っています。誰かがこれを行った場合、レビュー中にコードを渡すことはほとんどありません。

リフレクションを使用してメソッドを呼び出すことは、タイプセーフではなく、基礎となるクラスのプライベート メソッドが作り直されている場合に簡単に壊れてしまいます。

要するに、私は同意します、それは悪い考えです!

于 2009-11-28T06:26:30.240 に答える
1

これは、フレームワークから得られる高度な機能です。メソッドを呼び出すために本番コードで使用することは非常にまれであり、メンバーを非表示にする利点が損なわれます。

便利な場所がいくつかあります。

  • レガシ コード テスト- たとえば、レガシ コードを扱っていて、それを単体テストでカバーしたいとします。コードの変更が許可されておらず、機能のごく一部をテストしたい場合は、プライベート メソッドを呼び出すと便利です。
  • 本番コードのハック- あるシナリオでプライベート クリーンアップが行われないというサード パーティ コントロールのバグに遭遇しました。プライベート呼び出しを使用すると、回避できます。

この機能を提供するフレームワークには何の問題もありませんが、必須ではない場所で使用するのは間違っています。

于 2009-11-28T06:28:43.730 に答える