0

今日、興味深い質問が出てきました。コンストラクターの後に再設定する必要がないことがわかっているフィールドのセッターを優れたものにするのは良い習慣ですか?

PS もちろん、プライベート フィールドとゲッターとパブリック フィールドを使用する理由は理解していますが、それは理にかなっていますが、使用しない場合は本当にセッターを作成する必要がありますか?

PPS は特に Java を指しますが、どのプラットフォームでも問題ありません。

4

3 に答える 3

4

セッターを作成せず、コンストラクターを介してのみフィールドを設定できるようにすることで、不変フィールドを作成しました。クラスのインスタンスを作成すると、その値は変更されません。

注: getter によって返される値自体が変更可能な場合、上記のステートメントは成立しません。たとえば、 のインスタンスを返す場合ArrayList、誰かがその参照を使用して、そのリスト内の項目を追加および削除できます。java.util.Collections.unmodifiableListそれを修正するために見てください。getter で返すと、 aでもjava.util.Date変更できます。これを修正するには、JodaTime (または他の同様のサードパーティの日付クラス) を使用するか、Java 8 を待ちます。

私の謙虚な意見 (そして他の人の意見は常にそれほど謙虚であるとは限りません) では、不変性はソフトウェアのバグを減らし、保守を容易にする素晴らしいものです。

于 2013-08-30T23:15:14.680 に答える
2

それはただ依存します。

クラスがエクスポートされた API の一部であり、API のクライアントがセッターを使用する機会があると信じる理由がある場合は、セッターを含めることは理にかなっています。

ただし、ゲッターとセッターに関する真実は次のとおりです。

クラスにそれらがある場合、クラスは変更可能です。可変データと可変オブジェクトは、それらが何であるかです。この API が常にシングル スレッドになるように設計意図が指定されている場合、問題はありません。

ただし、シングル スレッド アプリであっても、可能な限り不変オブジェクトを作成することを目指す必要があります。不変オブジェクトの欠点は、getter と setter の役割がないことです (** 注を参照)。

妥協案は Builder パターンです (Bloch 氏らによる「Effective Java 2nd Ed.」)。このパターンでは、変更可能なヘルパー オブジェクトを使用してオブジェクトのフィールドを設定します。準備ができたら、ヘルパー オブジェクトは設定したデータを使用して、必要なオブジェクトの不変インスタンスを作成します。

変更可能なオブジェクトは、ニーズが単純で、競合や同時実行に関する懸念がない場合に使用してください。ただし、オブジェクトが可変であるほど、その状態を判断するのが難しくなることを覚えておいてください。そして、その状態を推論するのが難しくなればなるほど、不変条件を適用してセキュリティを維持することが難しくなる可能性があります。1 つの状態しか持てないオブジェクトは、これらの問題のほとんどすべてを解決します。特にクラスが値クラスの場合は、可能な場合は不変オブジェクトを作成するようにしてください。

(**) 注: もちろん、不変クラスのセッターを持つことは可能です。このような場合、セッターは新しい不変オブジェクトをインスタンス化し、その不変性を維持します。String クラスは、この戦略に依存しています。

于 2013-08-30T23:15:36.500 に答える
1

コンストラクターの後に再設定する必要がないことがわかっているフィールドのセッターを作成することは良い習慣ですか?

これが事前にわかっている場合は、必ずコードに記述してください。そのフィールドfinalを作成すると、コンパイラ自体がセッターを定義できないため、疑いはありません。

これにより、 「予想される可能性があるため」メソッドを作成する必要がなくなり、コードをクリーンで検証可能に保つための一歩でもあると思います。物事をそのまま宣言しているため、値の不変性をテストする必要もありません。

于 2013-08-30T23:19:19.437 に答える