項目 リフレクションよりもインターフェイスを優先する

Java でのリフレクション (java.lang.reflect):
リフレクションを通じて、次のことが可能になります。

• 任意のクラスのコンストラクター、メソッド、およびフィールドにプログラムでアクセスします。
• クラスとそのメンバー (コンストラクター、メソッド、フィールド) をリフレクティブな方法で操作し、インスタンスの作成、メソッドの呼び出し、フィールドへのアクセスを可能にします。
• コンパイル中にクラスが存在しない場合でも、オブジェクトのメソッドを呼び出します。

リフレクションのデメリット:
コンパイル時の型チェックの損失:

• 通常はコンパイル時に検出されるエラーは、実行時にのみ表示されます。
• 例: 存在しないメソッドまたはアクセスできないメソッドを反射的に呼び出すと、実行時に例外が生成される可能性があります。

重くて冗長なコード:
リフレクションには、より複雑で読みにくいコードが必要です。
例:

Method method = obj.getClass().getMethod("methodName");
method.invoke(obj, args);

パフォーマンス不足:

• リフレクティブ メソッドの呼び出しは、通常の呼び出しよりもかなり遅くなります。
• 例: 特定のシナリオでは、リフレクションは直接メソッド呼び出しよりも最大 11 倍遅くなる可能性があります。

リフレクションのアプリケーション:

• コード分析ツール、依存関係注入フレームワーク、サービス プロバイダー フレームワークで使用されます。
• このような状況であっても、デメリットがあるため、可能な限り回避する必要があります。

リフレクションの限定的使用:
推奨される手法: コンパイル時に未知のクラスをインスタンス化する場合にのみリフレクションを使用し、既知のインターフェイスまたはスーパークラスを通じてこれらのインスタンスを参照します。

例:
コマンドラインで指定された Set のインスタンスを作成するプログラム:

Class<? extends Set<String>> cl = (Class<? extends Set<String>>) Class.forName(args[0]);
Constructor<? extends Set<String>> cons = cl.getDeclaredConstructor();
Set<String> s = cons.newInstance();
for (int i = 1; i < args.length; i++) {
    s.add(args[i]);
}
System.out.println(s);

例で示されている欠点:
実行時例外:

• この例では、実行時に最大 6 つの異なる例外を生成できます。
• リフレクションが使用されていない場合、これらの例外はコンパイル時にキャッチされます。

複雑さと冗長さ:

• この例では、名前からクラスをインスタンス化するのに 25 行のコードが必要ですが、コンストラクターの直接呼び出しはわずか 1 行で実行されます。

未確認のキャスト警告:

• コマンドラインで指定されたクラスが Set の実装ではない可能性があるため、この例では、チェックされていないキャストに関する正当な警告が表示されます。

リフレクションの正当な使用:

• 動的依存関係: クラス、メソッド、またはフィールドが実行時に存在しない可能性がある場合。
• 例: リフレクションを使用すると、下位互換性を損なうことなく、パッケージの複数のバージョンをサポートできます。

結論:
反射は強力ですが、多くの欠点もあります。
可能な限り、オブジェクトをインスタンス化し、コンパイル時に既知のインターフェイスまたはスーパークラスを介してオブジェクトにアクセスする場合にのみリフレクションを使用してください。

本の例:

以上が項目 リフレクションよりもインターフェイスを優先するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。