11

私のプロジェクトでは、小さなデータ構造を持っていますKey。

public class Key implements Serializable {

  private static final long serialVersionUID = 1L;

  public String db;
  public String ref;
  public Object id;

  protected Key() {
  }

  public Key(String db, String ref, Object id) {
    this.db = db;
    this.ref = ref;
    this.id = id;
  }
}

はい、このクラスは単純で、すべてのフィールドに公開されています。

しかし、誰かが代わりにPOJOスタイルのクラスを使用することを提案しましたが、なぜ彼らが私に言うことができなかったのかと尋ねたとき。

私の意見では、ゲッターとセッターを呼び出すことは、フィールドに直接アクセスするよりも遅いです。

では、なぜPOJOプログラミングスタイルを使用する必要があるのでしょうか。

4

5 に答える 5

20

ウィキペディアからの引用：

POJOは、Plain OldJavaObjectの頭字語です。この名前は、特定のオブジェクトが特別なオブジェクトではなく、通常のJavaオブジェクトであることを強調するために使用されます。

POJOは通常単純なので、他のライブラリ、インターフェイス、または注釈に依存しません。これにより、これを複数のプロジェクトタイプ（Web、デスクトップ、コンソールなど）で再利用できる可能性が高くなります。

コメントで誰かがすでに指摘しているように、オブジェクトは技術的にはすでにPOJOですが、JavaBeansに似たゲッターとセッターについて具体的に質問しています。

ゲッターとセッターを使用する理由はいくつか考えられます。

  1. 一部の値のみを取得したい場合があります（つまり、読み取り専用の値）。フィールドを使用すると、クライアントは値を直接取得および設定できます。フィールドがfinalとしてマークされている場合、フィールドを読み取り専用にすることができますが、これは必ずしも不変であるとは限りません（ポイント9を参照）。
  2. Getterメソッドとsetterメソッドを使用すると、クラスのパブリックインターフェイスを壊すことなく、基になるデータ型を変更できます。これにより、クラス（およびアプリケーション）の堅牢性と変更に対する回復力が向上します。
  3. 値が取得または変更されたときに通知を発行するなど、他のコードを呼び出すこともできます。これは、現在のクラスでは不可能です。
  4. 場合によってはセキュリティリスクとなる可能性のあるクラスの実装を公開しています。
  5. Java BeanはPOJOを中心に設計されています。つまり、クラスが1つとして実装されていない場合、クラスがこれらの確立された原則に準拠することを期待する特定のツールやライブラリでは使用できません。
  6. フィールドの連結であるか、フィールドによって裏付けられているかなど、フィールドIEで計算された値に裏打ちされていない値を公開できます。getFullName()getFirstName()getLastName()
  7. セッターメソッドに検証を追加して、渡される値が正しいことを確認できます。これにより、クラスが常に有効な状態になります。
  8. ゲッターとセッターにブレークポイントを設定して、値が取得または変更されたときにコードをデバッグできるようにすることができます。
  9. フィールドがオブジェクト（つまり、プリミティブ型ではない）の場合、クラスの内部状態は他のオブジェクトによって変更される可能性があり、バグやセキュリティリスクにつながる可能性があります。オブジェクトのコピーを返すことで、POJOのゲッターでこのシナリオから保護できるため、クライアントはオブジェクトの状態に影響を与えることなくデータを操作できます。クライアントは参照されているオブジェクトに変更を加えることができるため（オブジェクト自体が可変である場合） 、最終フィールドがあると必ずしもこの種の攻撃から保護されるとは限らないことに注意してください。一度設定されたフィールドを別の参照に向けることはできません。 。

はい、メソッド呼び出しを介した値へのアクセスまたは設定は、直接のフィールドアクセスよりも遅い場合がありますが、違いはほとんど目立たず、プログラムのボトルネックにはなりません。

利点は明らかですが、これはゲッターとセッターが特効薬であることを意味するものではありません。実世界の堅牢でスケーラブルなクラスを設計する際に考慮すべき「落とし穴」がいくつかあります。

非常によく似た質問に対するこの回答では、ゲッターとセッターを含むクラスを設計する際の考慮事項について詳しく説明します。提案は、設計しているクラスのタイプによってはより適切な場合がありますが、EGは、単純なデータ転送オブジェクトではなく、大規模なシステムでAPIの一部を形成するクラスです。

また、速度が重要な場合やメモリが制限されている場合など、直接フィールドを持つクラスが有利な場合があることにも注意してください。ただし、これは、コードをプロファイリングして実際にボトルネックであることがわかった後でのみ検討する必要があります。

また、すべてのフィールドをゲッターとセッターでラップしているだけではないことに注意してください。これは、カプセル化のポイントが実際に欠落しているためです。

この回答は、ゲッターとセッターを備えたJavaBeanスタイルのオブジェクトではなくPOJOを選択する理由の概要を示しています。

于 2013-01-05T14:29:46.310 に答える
5

カプセル化を提供するプライベートクラス変数とパブリックゲッターおよびセッターを使用します。

于 2013-01-05T14:21:12.517 に答える
3

ゲッターとセッター、特に最も単純なフォームは、JITコンパイラーによってインライン化されるだけなので、メソッド呼び出しのオーバーヘッドがなくなります。これは時期尚早の最適化のように聞こえます。ボトルネックが発生した場合は、プロファイルを作成して、どこで発生するかを確認してください。私はそれがプロパティアクセスにはないだろうとかなり確信しています。

于 2013-01-05T14:21:34.543 に答える
3

効果的なJavaの本を手に入れてください。

  • 項目14は、パブリッククラスで、パブリックフィールドではなくアクセサメソッドを使用します。

この中で、Joshua Blochは、パッケージプライベートクラスまたはネストされたクラスのパブリックフィールドには本質的に問題はないと述べていますが、パブリッククラスの使用は強くお勧めしません。

彼はこの主題についてもっと詳しく説明します、それは素晴らしい本です、あなたがコピーを手に入れることを提案します。

于 2013-01-05T17:50:55.313 に答える
1

他のプログラマーがあなたのコードを使用していると想像してみてください。あなたがsetterメソッドとgetterメソッドを提供しない場合、彼はあなたの変数を直接呼び出すことができ、それは確かにあなたのコードに影響を与えます。また、セキュリティの問題が発生する可能性があるため、POJOクラスを提供することで、インスタンス変数を直接呼び出すのではなく、メソッドを呼び出すように強制します。

于 2015-03-02T06:20:08.220 に答える