特に非公開メンバーへの反省は間違っている
- リフレクションはタイプ セーフを破ります。(もう) 存在しない、または間違ったパラメーターを使用して、またはパラメーターが多すぎるか、十分でない、または間違った順序でメソッドを呼び出そうとすることができます (これは私のお気に入りです :) )。ちなみに、戻り値の型も変更される可能性があります。
- 反射が遅い。
プライベート メンバー リフレクションはカプセル化の原則を破るため、コードを次のように公開します。
- クラスの内部動作を処理する必要があるため、コードの複雑さが増します。隠されているものは隠されたままであるべきです。
- コードはコンパイルされますが、メソッドの名前が変更された場合は実行されないため、コードを簡単に壊すことができます。
- プライベート コードが壊れやすくなります。プライベート コードは、そのように呼び出されることを意図していないためです。おそらく、プライベート メソッドは、呼び出される前に何らかの内部状態を想定しています。
とにかくそれをしなければならない場合はどうなりますか?
サードパーティに依存したり、公開されていないAPIが必要な場合は、いくつかのリフレクションを行う必要がある場合があります. 所有しているいくつかのクラスをテストするためにそれを使用する人もいますが、テストのためだけに内部メンバーにアクセスできるようにインターフェイスを変更したくありません。
やるならちゃんとやれよ
破損しやすい問題を軽減するには、継続的インテグレーション ビルドなどで実行される単体テストでテストすることにより、潜在的な破損を検出することをお勧めします。もちろん、これは常に同じアセンブリ (プライベート メンバーを含む) を使用することを意味します。動的なロードとリフレクションを使用する場合は、火遊びが好きですが、呼び出しが生成する可能性のある例外をいつでもキャッチできます。
.Net Framework の最近のバージョンでは、CreateDelegate は MethodInfo 呼び出しを 50 倍上回っています。
// The following should be done once since this does some reflection
var method = this.GetType().GetMethod("Draw_" + itemType,
BindingFlags.NonPublic | BindingFlags.Instance);
// Here we create a Func that targets the instance of type which has the
// Draw_ItemType method
var draw = (Func<TInput, Output[]>)_method.CreateDelegate(
typeof(Func<TInput, TOutput[]>), this);
draw
呼び出しは、そのような標準としてMethodInfo.Invoke
使用するよりも約 50 倍高速になります。draw
Func
var res = draw(methodParams);
この投稿をチェックして、さまざまなメソッド呼び出しのベンチマークを確認してください