プライベートゲッターではなくパブリックファイターを使用する

ほとんどの不変のPOJOは次のように書かれています：

public class MyObject {
    private final String foo;
    private final int bar;

    public MyObject(String foo, int bar) {
        this.foo = foo;
        this.bar = bar;
    }

    public String getFoo() {
        return foo;
    }

    public int getBar() {
        return bar;
    }
}

しかし、私は次のようにそれらを書く傾向があります。

public class MyObject {
    public final String foo;
    public final int bar;

    public MyObject(String foo, int bar) {
        this.foo = foo;
        this.bar = bar;
    }
}

参照は最終的なものなので、オブジェクトは不変のままです。これにより、より少ないコードを記述でき、より短い（5文字ずつ：getおよび()）アクセスが許可されます。

私が見ることができる唯一の欠点は、getFoo()何かおかしなことをするために将来の実装を変更したい場合、できないということです。しかし現実的には、オブジェクトは不変であるため、これは決して起こりません。インスタンス化中に検証し、インスタンス化中に不変の防御コピーを作成し（ImmutableListたとえばGuavaを参照）、オブジェクトfooまたはbarオブジェクトをget呼び出しの準備ができます。

欠けている欠点はありますか？

編集

私が見逃している別の欠点は、getまたはisで始まるメソッドのリフレクションを使用するシリアル化ライブラリであると思いますが、それはかなり恐ろしい習慣です...

私が考えることができる4つの欠点：

1. 同じエンティティの読み取り専用で変更可能な形式が必要な場合、一般的なパターンは、保護されたメンバー変数を持つアクセサーのみを公開する不変クラスEntityを持ち、それを拡張してセッターを追加するMutableEntityを作成することです。あなたのバージョンはそれを防ぎます。
2. ゲッターとセッターの使用は、JavaBeans規約に準拠しています。クラスをJSTLやELなどのプロパティベースのテクノロジーでBeanとして使用する場合は、パブリックゲッターを公開する必要があります。
3. 実装を変更して値を取得したり、データベースでそれらを検索したい場合は、クライアントコードをリファクタリングする必要があります。アクセサー/ミューテーターアプローチでは、実装のみを変更できます。
4. 最小限の驚き-パブリックインスタンス変数を見ると、誰がそれを変更しているのかをすぐに探し、カプセル化が失われるためにpandoraのボックスを開くのではないかと心配します。 http://en.wikipedia.org/wiki/Principle_of_least_astonishment

とは言っても、バージョンは間違いなく簡潔です。これが特定のパッケージ内でのみ使用される特殊なクラスである場合（ここではパッケージスコープがよい考えかもしれません）、これを1回限りと見なすことができます。ただし、このような主要なAPIは公開しません。

ゲッター/セッターも削除してください、あなたは大丈夫です！

これは、Javaプログラマーの間で非常に議論の多いトピックです。

とにかく、ゲッター/セッターの代わりにパブリック変数を使用する2つの状況があります：

1. public final私にとって、これは単なる「ゲッター」よりも「不変」だということを示しています。ほとんどのIDEは、オートコンプリート中に最終修飾子を「F」で示します。setXXXがないことを検索する必要があるゲッター/セッターとは異なります。
2. public non-final私はこれをデータクラスで気に入っています。すべてのフィールドを公開するだけです。ゲッター、セッター、コンストラクターはありません。いいえ、別に。ポージョ未満。私にとって、これはすぐに「見て、馬鹿だ。データを保持している、それだけだ。正しいデータを自分の中に入れるのはあなたの仕事だ」と合図する。Gson / JAXB /など これらのクラスをうまく処理します。彼らは書くのが至福です。彼らの目的や能力に疑いの余地はありません。そして最も重要なことは、変数を変更しても副作用がないことです。私見では、これにより、曖昧さがほとんどない非常に簡潔なデータモデルが得られますが、ゲッターとセッターには、内部で魔法が発生することがあるという大きな問題があります。

素人の言葉で：

• 数行のコードを保存するために、カプセル化に違反します。それはOODの目的に反します。
• クライアントコードは、クラスメンバーの名前にハードカップリングされます。カップリングは悪いです。OODの全体的な目的は、結合を防ぐことです。
• また、クラスが変更可能である必要はないことも確信しています。物事は変わります。変化は一定である唯一のものです。

私が目にする可能性のある欠点の1つは、クラス内のデータの内部表現に縛られていることです。これはおそらく大した問題ではありませんが、セッターを使用し、fooとbarが別の場所で定義された他のクラスから返されると決定した場合、MyObjectを使用するクラスを変更する必要はありません。MyObjectをタッチするだけです。ただし、裸の値を使用する場合は、MyObject iを使用したすべての場所をタッチする必要があります。