基本的に、リフレクションとは、プログラムのコードをデータとして使用することを意味します。
したがって、プログラムのコードが有用なデータソースである場合、リフレクションを使用することをお勧めします。（ただし、トレードオフがあるため、常に良いアイデアとは限りません。）
たとえば、単純なクラスを考えてみましょう。
public class Foo {
public int value;
public string anotherValue;
}
そしてそこからXMLを生成したい。XMLを生成するコードを書くことができます。
public XmlNode generateXml(Foo foo) {
XmlElement root = new XmlElement("Foo");
XmlElement valueElement = new XmlElement("value");
valueElement.add(new XmlText(Integer.toString(foo.value)));
root.add(valueElement);
XmlElement anotherValueElement = new XmlElement("anotherValue");
anotherValueElement.add(new XmlText(foo.anotherValue));
root.add(anotherValueElement);
return root;
}
しかし、これは大量の定型コードであり、クラスを変更するたびにコードを更新する必要があります。本当に、このコードが何をするのかを説明できます
- クラスの名前でXML要素を作成します
- クラスの各プロパティに対して
- プロパティの名前でXML要素を作成します
- プロパティの値をXML要素に入れます
- XML要素をルートに追加します
これはアルゴリズムであり、アルゴリズムの入力はクラスです。その名前と、プロパティの名前、型、値が必要です。これがリフレクションの出番です。この情報にアクセスできます。Javaでは、Classクラスのメソッドを使用して型を検査できます。
さらにいくつかのユースケース：
- クラスのメソッド名に基づいてWebサーバーでURLを定義し、メソッドの引数に基づいてURLパラメーターを定義する
- クラスの構造をGraphQL型定義に変換します
- ユニットテストケースとして名前が「test」で始まるクラスのすべてのメソッドを呼び出します
ただし、完全なリフレクションとは、既存のコード（それ自体が「イントロスペクション」と呼ばれる）を調べるだけでなく、コードを変更または生成することも意味します。Javaには、プロキシとモックという2つの顕著なユースケースがあります。
インターフェースがあるとしましょう：
public interface Froobnicator {
void froobnicateFruits(List<Fruit> fruits);
void froobnicateFuel(Fuel fuel);
// lots of other things to froobnicate
}
そして、あなたは何か面白いことをする実装を持っています：
public class PowerFroobnicator implements Froobnicator {
// awesome implementations
}
実際、2番目の実装もあります。
public class EnergySaverFroobnicator implements Froobnicator {
// efficient implementations
}
ログ出力も必要になりました。メソッドが呼び出されるたびにログメッセージが必要になります。ログ出力をすべてのメソッドに明示的に追加することもできますが、それは面倒であり、2回行う必要があります。実装ごとに1回。（実装を追加するとさらに多くなります。）
代わりに、プロキシを作成できます。
public class LoggingFroobnicator implements Froobnicator {
private Logger logger;
private Froobnicator inner;
// constructor that sets those two
public void froobnicateFruits(List<Fruit> fruits) {
logger.logDebug("froobnicateFruits called");
inner.froobnicateFruits(fruits);
}
public void froobnicateFuel(Fuel fuel) {
logger.logDebug("froobnicateFuel( called");
inner.froobnicateFuel(fuel);
}
// lots of other things to froobnicate
}
繰り返しますが、アルゴリズムで説明できる繰り返しパターンがあります。
- ロガープロキシは、インターフェイスを実装するクラスです
- インターフェースとロガーの別の実装を取るコンストラクターがあります
- インターフェイス内のすべてのメソッドに対して
- 実装は「$ methodname called」というメッセージを記録します
- そして、内部インターフェイスで同じメソッドを呼び出し、すべての引数を渡します
このアルゴリズムの入力はインターフェイス定義です。
Reflectionでは、このアルゴリズムを使用して新しいクラスを定義できます。Javaでは、java.lang.reflect.Proxyクラスのメソッドを使用してこれを行うことができ、さらに強力なライブラリがあります。
では、反射のマイナス面は何ですか？
- コードが理解しにくくなります。あなたはコードの具体的な効果からさらに取り除かれた抽象化の一つのレベルです。
- コードのデバッグが難しくなります。特にコード生成ライブラリの場合、実行されるコードは作成したコードではなく、生成したコードであり、デバッガーはそのコードを表示できない（またはブレークポイントを配置できる）場合があります。
- コードが遅くなります。型情報を動的に読み取り、ハードコーディングアクセスの代わりにランタイムハンドルによってフィールドにアクセスするのは遅くなります。動的なコード生成は、デバッグがさらに困難になるという犠牲を払って、この影響を軽減できます。
- コードがより脆弱になる場合があります。動的リフレクションアクセスはコンパイラによって型チェックされませんが、実行時にエラーをスローします。