Reflectionの使用に問題はありますか？

理由はわかりませんが、リフレクションを使用するときは常に「ごまかし」のような気がします-おそらく、自分が取っているパフォーマンスヒットのせいでしょう。

私の一部は、それがあなたが使用している言語の一部であり、あなたがしようとしていることを達成できるなら、なぜそれを使用しないのかと言います。私の他の部分は、リフレクションを使用せずにこれを行うことができる方法がある必要があると言います。多分それは状況次第だと思います。

リフレクションを使用する際に注意する必要のある潜在的な問題は何ですか？従来の解決策を見つけようとするのにどれだけの労力を費やす価値がありますか？

いいえ、不正行為ではありません。これは、一部のプログラミング言語の問題を解決する方法です。

現在では、最良の（最もクリーンで、シンプルで、保守しやすい）ソリューションではないことがよくあります。より良い方法があれば、実際にそれを使用してください。ただし、そうでない場合もあります。または、存在する場合、それは非常に複雑で、多くのコードの複製などを伴い、実行不可能になります（長期的に維持するのが困難です）。

現在のプロジェクトの2つの例（Java）：

• 一部のテストツールでは、リフレクションを使用してXMLファイルから構成を読み込みます。初期化されるクラスには特定のフィールドがあり、構成ローダーはリフレクションを使用してfieldX、クラス内の適切なフィールドに名前が付けられたXML要素を照合し、後者を初期化します。場合によっては、識別されたプロパティからその場で簡単なGUIダイアログボックスを構築できます。リフレクションがなければ、これは複数のアプリケーションにわたって数百行のコードを必要とします。そのため、リフレクションを使用することで、大したことなく簡単なツールをすばやくまとめ、重要ではない部分（Webアプリのテスト、サーバーログの分析など）に集中できるようになりました。
• 従来のWebアプリの1つのモジュールは、DBテーブルからExcelシートにデータをエクスポート/インポートすることを目的としていました。重複したコードがたくさんありましたが、もちろん重複はまったく同じではなく、バグの一部も含まれていました。リフレクション、イントロスペクション、注釈を使用して、重複のほとんどを排除し、コードの量を削減しましたコードをより堅牢にし、保守や拡張をより簡単にする一方で、5Kから2.4K未満。リフレクションの賢明な使用のおかげで、そのモジュールは私たちにとって問題ではなくなりました。

一番下の行は、他の強力なツールと同様に、反射も足で自分を撃つために使用することができます。いつ、どのように使用する（しない）かを学習すれば、それ以外の難しい問題に対するエレガントでクリーンなソリューションを提供できます。悪用すると、他の点では単純な問題を複雑でい混乱に変えることができます。

不正行為ではありません。しかし、少なくとも以下の理由から、通常は実動コードでは悪い考えです。

• コンパイル時の型の安全性が失われます -コンパイル時にメソッドが利用可能であることをコンパイラに確認させると役に立ちます。リフレクションを使用している場合、十分なテストを行わないと、実行時にエラーが発生し、エンドユーザーに影響を与える可能性があります。エラーをキャッチしたとしても、デバッグはより困難になります。
• リファクタリング時にバグが発生します-名前に基づいてメンバーにアクセスしている場合（ハードコードされた文字列を使用する場合など）、ほとんどのコードリファクタリングツールによって変更されず、すぐにバグが発生します。追跡するのは難しい。
• パフォーマンスは遅くなります -実行時のリフレクションは、静的にコンパイルされたメソッド呼び出し/変数検索よりも遅くなります。たまにリフレクションを行う場合は重要ではありませんが、リフレクションを介して毎秒数千または数百万回呼び出しを行う場合、これがパフォーマンスのボトルネックになる可能性があります。一度すべてのリフレクションを排除することで、Clojureのコードを10倍高速化したことがあるので、これは本当の問題です。

リフレクションの使用を次の場合に限定することをお勧めします。

• 以下のための迅速なプロトタイピングや、それが最も簡単な解決策がある「使い捨て」のコード
• 以下のための本物の反射ユースケース、ユーザーが実行時に任意のオブジェクトのフィールド/メソッドを調べることができ、例えばIDEツーリング。

その他の場合はすべて、反射を回避するアプローチを考え出すことをお勧めします。適切なメソッドでインターフェイスを定義し、メソッドを呼び出すクラスのセットに実装することで、ほとんどの単純なケースを解決できます。

リフレクションは、最近のほとんどの言語で見られる型ベースのパラメーターと同様に、メタプログラミングの別の形式であり、同様に有効です。リフレクションは強力で汎用的であり、リフレクションプログラムは（もちろん正しく使用すると）保守性が高く、オブジェクト指向プログラムまたは手続き型プログラムよりも優れています。はい、パフォーマンスの価格をお支払いいただきますが、多くの場合、またはほとんどの場合でも、より保守しやすい低速のプログラムを喜んでお勧めします。

確かにそれはあなたが何を達成しようとしているかに依存します。

たとえば、依存性注入を使用して、チェックするメディアの種類（MP3ファイルまたはJPEGファイル）を決定するメディアチェッカーアプリケーションを作成しました。シェルは、各タイプに関連する情報を含むグリッドを表示する必要がありましたが、何を表示するのかを知りませんでした。これは、そのタイプのメディアを読み取るアセンブリで定義されます。

したがって、グリッドを正しく設定できるように、表示する列の数とそのタイプと名前を取得するためにリフレクションを使用する必要がありました。また、他のコードや構成ファイルを変更せずに、挿入したライブラリを更新（または新しいライブラリを作成）できることも意味していました。

他の唯一の方法は、チェックするメディアのタイプを切り替えたときに更新する必要がある構成ファイルを保持することでした。これにより、アプリケーションに別の障害点が生じていました。

ライブラリ作成者である場合、Reflectionは素晴らしいツールであるため、受信データに影響を与えません。リフレクションとメタプログラミングを組み合わせることで、ライブラリを任意の呼び出し元とシームレスに連携させることができます。コード生成などを行う必要はありません。

ただし、アプリケーションコードのリフレクションを阻止しようとしています。アプリ層では、インターフェイス、抽象化、カプセル化など、さまざまなメタファーを使用する必要があります。

Reflectionは、開発者向けのツールを構築するのに最適です。

ビルド環境でコードを検査し、コードを操作/初期化するための適切なツールを潜在的に生成できるためです。

一般的なプログラミング手法としては有用ですが、ほとんどの人が想像するよりも脆弱です。

リフレクション（IMO）の実際の開発用途の1つは、一般的なストリーミングライブラリの作成を非常に簡単にすることです（クラス記述が変更されない限り（その後、非常に脆弱なソリューションになります））。

リフレクションの使用は、よく意識して使用しないと、オブジェクト指向言語ではしばしば有害です。

StackExchangeサイトで見た悪い質問の数を失いました。

1. 使用中の言語はオブジェクト指向です
2. 作成者は、どのタイプのオブジェクトが渡されたかを調べ、そのメソッドの1つを呼び出したい
3. 著者は、反省が間違った手法であることを受け入れることを拒否し、これを「私を助ける方法がわからない」と指摘する人を非難します

以下 に典型的な例を示します。

オブジェクト指向のポイントのほとんどは

1. あなたは物自体で構造/概念を操作する方法を知っている関数をグループ化します。
2. コードのどの時点でも、オブジェクトのタイプについて十分に知って、関連する関数を把握し、それらの関数の特定のバージョンを呼び出すように依頼する必要があります。
3. すべての関数に正しい入力タイプを指定し、各関数に関連する情報以上の情報（およびそれ以上の情報）を持たせないようにすることで、前のポイントの真実を確認します。

コードのいずれかの時点で、渡されたオブジェクトに対してポイント2が有効でない場合、これらの1つ以上が真です

1. 間違った入力が入力されています
2. コードの構造が不十分です
3. あなたは一体何をしているのか分かりません。

スキルの低い開発者はこれを取得せず、コードのどの部分でも何でも渡すことができ、（ハードコーディングされた）可能性のセットから必要なことを実行できると信じています。これらのバカは反射をよく使います。

OO言語の場合、リフレクションはメタアクティビティ（クラスローダー、依存性注入など）でのみ必要です。これらのコンテキストでは、適切で正当な理由で何も知らないコードの操作/構成を支援する汎用サービスを提供しているため、リフレクションが必要です。他のほとんどの状況では、リフレクションに手を伸ばす場合、何か間違ったことをしているので、渡されたオブジェクトについてこのコードが十分に知らない理由を自問する必要があります。

代替として、リフレクションされたクラスのドメインが明確に定義されている場合、実行時にリフレクションを使用する代わりに、リフレクションと他のメタデータを使用してコードを生成することです。FreeMarker / FMPPを使用してこれを行います。から選択する他のツールがたくさんあります。これの利点は、簡単にデバッグできる「実際の」コードなどになることです。

状況に応じて、これによりコードを大幅に高速化することができます-または単にコードを大量に膨張させることができます。リフレクションの欠点を回避します。

• コンパイル時の型安全性の喪失
• リファクタリングによるバグ
• 遅いパフォーマンス

先に述べた。

リフレクションが不正行為のように感じる場合、それはあなたがよくわからない多くの当て推量に基づいているためであり、あなたの腸はこれが危険であることを警告しています。リフレクションに固有のメタデータを独自のメタデータで強化する方法を必ず提供してください。ここでは、発生する可能性のある実際のクラスのすべての癖と特殊なケースを説明できます。

不正行為ではありませんが、他のツールと同様に、解決するために使用する必要があります。定義により、リフレクションを使用すると、コードを介してコードを検査および変更できます。それがあなたがする必要があるものであるなら、反射は仕事のためのツールです。リフレクションはメタコードに関するものです。コードをターゲットとするコード（データをターゲットとする通常のコードとは対照的）。

適切なリフレクションの使用例は、汎用Webサービスインターフェイスクラスです。典型的な設計は、プロトコル実装をペイロード機能から分離することです。そのTため、ペイロードを実装する1つのクラス（呼び出しましょう）と、プロトコルを実装する別のクラス（）がありますP。Tかなり簡単です。あなたがしたいすべての呼び出しについて、それがすることになっていることを何でもする1つのメソッドを単に書いてください。Pただし、Webサービス呼び出しをメソッド呼び出しにマップする必要があります。冗長性を回避し、P再利用性を高めるため、このマッピングを汎用にすることが望ましいです。Reflectionは、T実行時にクラスを検査し、クラスのPコンパイル時の知識なしに、Webサービスプロトコルを介して渡された文字列に基づいてメソッドを呼び出す手段を提供します。T。「コードに関するコード」ルールを使用すると、クラスのデータの一部としてPクラス内にコードがあると主張できTます。

しかしながら。

Reflectionでは、言語の型システムの制限を回避するためのツールも提供されます。理論的には、すべてのパラメータをtypeとして渡しobject、リフレクションを通じてメソッドを呼び出すことができます。強力な静的型付け規則を実施することになっている言語であるVoilàは、構文がはるかに複雑であることだけが、遅延バインディングを備えた動的型付け言語のように動作します。私がこれまでに見たそのようなパターンのすべてのインスタンスは汚いハックであり、常に言語の型システム内の解決策が可能であり、あらゆる点でより安全で、よりエレガントで、より効率的でした。 。

いくつかの例外があります。たとえば、さまざまな非関連タイプのデータソースにデータバインドできるGUIコントロールなどです。データをバインドできるようにデータに特定のインターフェイスを実装するように命じることは現実的ではなく、プログラマーに各タイプのデータソース用のアダプターを実装させることもありません。この場合、リフレクションを使用してデータソースの種類を検出し、データバインディングを調整する方が便利な選択です。

Reflectionで発生した問題の1つは、難読化をミックスに追加したことです。すべてのクラスは新しい名前を取得し、クラスまたは関数をその名前で突然ロードすると動作しなくなります。

それは完全に依存します。リフレクションなしで行うのが難しいことの例は、ObjectListViewを複製することです。また、その場でILコードを生成します。

リフレクションは、コンベンションベースのシステムを作成する主な方法です。ほとんどのMVCフレームワーク内で使用されていることに驚かないでしょう。これはORMの主要なコンポーネントです。おそらく、あなたはすでにそれで構築されたコンポーネントを毎日使用しています。

このような使用の代替手段は構成であり、独自の欠点があります。

リフレクションは、他の方法では実際に実行できないことを実現できます。

たとえば、このコードを最適化する方法を検討してください。

int PoorHash(char Operator, int seed, IEnumerable<int> values) {
    foreach (var v in values) {
        seed += 1;
        switch (char) {
            case '+': seed += v; break;
            case '^': seed ^= v; break;
            case '-': seed -= v; break;
            ...
        }
        seed *= 3;
    }
    return seed;
}

内側のループの真ん中に高価なテストスマックがありますが、それを抽出するには、各演算子に対してループを1回書き換える必要があります。Reflectionを使用すると、ループを数十回繰り返すことなく、テストを抽出するのと同等のパフォーマンスを得ることができます（したがって、保守性が犠牲になります）。必要なループをその場で生成してコンパイルするだけです。

私は実際にこの最適化を行いましたが、状況はもう少し複雑で、結果は驚くべきものでした。パフォーマンスが大幅に向上し、コードの行数が少なくなりました。

（注：最初はcharではなくFuncを渡すのと同等の方法を試しましたが、わずかに改善されましたが、10倍の反射はほとんど達成されませんでした。）

不正行為ではありません...むしろ、アプリケーションサーバーがユーザーが選択した名前で作成したクラスを実行できるようにし、不正行為ではなく柔軟性をユーザーに提供します。

また、Javaの.classファイルのコードを表示したい場合は、いくつかの逆コンパイラが無料で利用できます！