オブジェクトのプライベートフィールドの読み取りと書き込みは、アクセサなしで、ただしリフレクションを使用して実行できることを発見しました。
したがって、私の質問は、サードテクノロジー(ELなど)を使用しないアプリケーションの場合、JAVAで、たとえば20個のフィールドを含むPOJOが必要な場合、40個のアクセサーを実装するか、リフレクションを使用してそれらにアクセスしますか?私はいくつかの賛否両論を推測しますが、どんな経験やフィードバックも素晴らしいでしょう:)
オブジェクトのプライベートフィールドの読み取りと書き込みは、アクセサなしで、ただしリフレクションを使用して実行できることを発見しました。
したがって、私の質問は、サードテクノロジー(ELなど)を使用しないアプリケーションの場合、JAVAで、たとえば20個のフィールドを含むPOJOが必要な場合、40個のアクセサーを実装するか、リフレクションを使用してそれらにアクセスしますか?私はいくつかの賛否両論を推測しますが、どんな経験やフィードバックも素晴らしいでしょう:)
できますが、あまり保守できないので、そうしないでください。getter / setterを使用してメンバーにアクセスすることの利点は、アクセサーを非表示にし、レイジーを初期化し、簡単にリファクタリングできることです(たとえば、IDEAまたはEclipseを使用)。
リフレクションを使用してオブジェクトのフィールドとメソッドにアクセスできますが、アクセスしないでください。
この記事には、少なくとも2つの測定可能な理由が記載されています。
パフォーマンス。リフレクションを使用したオブジェクトメソッド/フィールドへのアクセスは、アクセサーを介したアクセスよりも遅くなります。
セキュリティ制限
そして最大の欠点は、以下の記事から引用すると、保守性がないことです。
多くのアプリケーションのより深刻な欠点は、リフレクションを使用すると、コード内で実際に何が起こっているのかがわかりにくくなる可能性があることです。プログラマーは、ソースコードにプログラムのロジックが含まれていることを期待しており、ソースコードをバイパスするリフレクションなどの手法により、メンテナンスの問題が発生する可能性があります。
リフレクションを使用して使用可能なフィールドを把握している場合でも、一般的にはゲッターを介してフィールドにアクセスすることをお勧めします。リフレクションを介して利用可能なゲッターを簡単に把握し、それらのゲッターメソッドを呼び出すことができます。これにより、次のことが可能になります。
1)利用可能なデータを動的に把握します。
2)どのフィールドを使用可能にし、どのフィールドをプライベートにする必要があるかを明示的に示します。
3)ニーズに合わせて、ゲッターの動作を明示的にオーバーライドします。
ほとんどの場合、リフレクションは、オブジェクトで使用可能なデータを把握するために使用されます。ゲッターとセッターの一般的な代替としてリフレクションを使用しないでください。そうしないと、コードが本当に保守できなくなります。
リフレクションは、オブジェクトの構造について多くを想定することなく、オブジェクトに魔法をかける必要がある特定のユースケースにのみ適しています。具体的には、JVMがを使用している場合、SecurityManager
リフレクションを介してコードがプライベートを設定するのを妨げる可能性があります。
セキュリティマネージャの詳細については、この他の質問を参照してください。