私が一緒に働いていて尊敬している誰かが、アプリケーションコードでリフレクションを使用する必要はなく、フレームワークでのみ使用する必要があると私に言ったことがあります。彼は J2EE のバックグラウンドから話していましたが、そのプラットフォームに関する私の専門的な経験は、一般的にそれを裏付けています。ただし、Java を使用してリフレクション アプリケーション コードを 1 回か 2 回作成したことがあります。
私の Ruby on Rails の経験は根本的に異なります。なぜなら、Ruby は動的コードを書くことをかなり奨励するからです。Rails が提供する機能の多くは、リフレクションとメタプログラミングなしでは不可能であり、同じ手法の多くは、アプリケーション コードに同様に適用可能であり、有用です。
静的に型付けされた言語で書かれた十分に洗練されたシステムには、Lispの不完全で劣った実装が含まれているという古いジョークがあります。
プロジェクトが進展するにつれて要件はより複雑になる傾向があるため、静的に型付けされたオブジェクトシステムの一般的なイディオムが最終的に壁にぶつかることに気付くことがよくあります。時々、反省に手を伸ばすことが最善の解決策です。
Rubyのような動的型付け言語とC＃のような静的型付け言語には満足していますが、Rubyでの暗黙の反映により、コードがより単純で読みやすくなることがよくあります。（必要なメタプログラミングの魔法によっては、書くのが難しい場合もあります）。
C＃では、実行時まで持っていなかった情報のために、反省なしでは解決できない問題を見つけました。1つの例：別のプロセスで実行されているSilverlightオブジェクトのプロキシを生成するサードパーティのコードを操作しようとすると、マーシャリングで呼び出し元が他のプロセスのオブジェクトのタイプについては、そこから必要なデータを抽出するためのものであり、C＃では、実行時に汎用メソッド呼び出しの「タイプ」を指定することはできません（リフレクションを除く）。テクニック）。私たちのツールは一種のフレームワークであると言えるかもしれませんが、通常のアプリケーションで同様の問題に直面しているケースは簡単に想像できます。
リフレクションは DRY をより簡単にします。リフレクションなしで DRY コードを書くことは確かに可能ですが、多くの場合、はるかに冗長です。
プログラム内で何らかの情報が何らかの方法でエンコードされている場合、それが最も簡単な方法である場合、リフレクションを使用してそれを取得しないのはなぜでしょうか?
彼は特に Java について話しているようです。その場合、彼はこれの特別なケースを引用しているだけです.Javaでは、リフレクションは非常に不安定で、何かを行うための最も簡単な方法はほとんどありません. :-) Ruby のような他の言語では、これまで見てきたように、よくあることです。
リフレクションはフレームワークで多用されることは間違いありませんが、正しく使用すると、アプリケーションのコードを簡素化するのに役立ちます。
私が以前に見た 1 つの例は、大きなインターフェイス (20 以上のメソッド) の JDK プロキシを使用して、特定の実装をラップ (つまり、委譲) することです。いくつかのメソッドのみが InvocationHandler を使用してオーバーライドされ、残りのメソッドはリフレクションを介して呼び出されました。
リフレクションは便利ですが、通常のメソッド呼び出しよりも遅くなります。この反射比較を参照してください。
他に方法がない場合は、リフレクションを使用してください。これはパフォーマンスの問題です！
以前に .NET パフォーマンスの落とし穴を調べたことがあれば、通常のリフレクションがどれほど遅いかは驚くことではないかもしれません: int プロパティへの繰り返しアクセスによる単純なテストでは、プロパティへの直接アクセスと比較して、リフレクションを使用すると最大 1000 倍遅くなることが証明されました。 (測定時間の中央値 80% の平均を比較)。
これを参照してください: .NET リフレクション - パフォーマンス
MSDN には、いつリフレクションを使用する必要があるかについての非常に優れた記事があります。
私は同意しません。リフレクションはアプリケーション コードで非常に便利であり、頻繁に使用しています。最近では、リフレクションを使用して、アセンブリのパスだけからアセンブリを読み込む必要がありました (そのパブリック型を調査するため)。
このテーマに関するいくつかの意見がここで表明されています...
私のアプリケーションはリフレクションを使用してプロバイダーを動的に作成します。ロジックが単純で、より複雑なパターンが必要ない場合は、リフレクションを使用してロジック フローを制御することもできます。
C# では、リフレクションを使用して列挙から属性を取得します。これは、列挙をエンド ユーザーに表示する方法を決定するのに役立ちます。
アプリケーションコードでリフレクションを使用する必要はなく、フレームワークでのみ使用する必要があるという観察は、多かれ少なかれ真実だと思います。
コードの一部がどのように結合されているかという観点から見ると、リフレクションによって結合されたコードは、本来疎結合です。
そのため、リフレクションを介して仕事をしているコードは、それを使用しているコードについて何も知らずに、生活の中でその役割を非常に喜んで果たすことができます。
リフレクションを使用して問題を解決するのが最善の場合は、リフレクションを使用する必要があります。
（「最高」の定義は経験によって学んだものであることに注意してください:)
フレームワークとアプリケーションの定義も、それほど白黒ではありません。アプリがうまく機能するために、少しフレームワークが必要な場合があります。