不変オブジェクトはすべてのプロパティがfinal
でなければなりませんか?
私によればそうではない。しかし、私が正しいかどうかはわかりません。
不変オブジェクト(すべてのプロパティが最終)と効果的に不変オブジェクト(プロパティは最終ではないが変更できない)の主な違いは、安全な公開です。
最終フィールド用のJavaメモリモデルによって提供される保証のおかげで、同期の追加について心配することなく、マルチスレッドコンテキストで不変オブジェクトを安全に公開できます :
finalフィールドを使用すると、プログラマは同期せずにスレッドセーフな不変オブジェクトを実装できます。スレッド間で不変オブジェクトへの参照を渡すためにデータ競合が使用されている場合でも、スレッドセーフな不変オブジェクトはすべてのスレッドで不変と見なされます。これにより、不正確または悪意のあるコードによる不変クラスの誤用に対する安全性が保証されます。不変性の保証を提供するには、最終フィールドを正しく使用する必要があります。
補足として、不変性を強制することもできます(不変であることを忘れたためにクラスの将来のバージョンでそれらのフィールドを変更しようとすると、コンパイルされません)。
説明
final List
が含まれている場合、変更操作はありません(追加、削除...)は構築後に行う必要があります)および(ii)構築中にthis
をエスケープさせない安全でない公開の例:
class EffectivelyImmutable {
static EffectivelyImmutable unsafe;
private int i;
public EffectivelyImmutable (int i) { this.i = i; }
public int get() { return i; }
}
// in some thread
EffectivelyImmutable.unsafe = new EffectivelyImmutable(1);
//in some other thread
if (EffectivelyImmutable.unsafe != null
&& EffectivelyImmutable.unsafe.get() != 1)
System.out.println("What???");
このプログラムは、理論的にはWhat???
を出力できます。 i
が最終的なものである場合、それは法的な結果にはなりません。
カプセル化のみで不変性を簡単に保証できるので、必要ではありません:
// This is trivially immutable.
public class Foo {
private String bar;
public Foo(String bar) {
this.bar = bar;
}
public String getBar() {
return bar;
}
}
ただし、必要な場合もありますカプセル化によってそれを保証するため、十分ではありません:
public class Womble {
private final List<String> cabbages;
public Womble(List<String> cabbages) {
this.cabbages = cabbages;
}
public List<String> getCabbages() {
return cabbages;
}
}
// ...
Womble w = new Womble(...);
// This might count as mutation in your design. (Or it might not.)
w.getCabbages().add("cabbage");
些細なエラーをキャッチし、意図を明確に示すためにそうすることは悪い考えではありませんが、「すべてのフィールドは最終的なもの」と「クラスは不変」は同等のステートメントではありません。
不変=変更できません。したがって、プロパティをfinalにすることは良い考えです。オブジェクトのすべてのプロパティが変更されないように保護されていない場合、オブジェクトが不変であるとは言えません。
ただし、プライベートプロパティのセッターを提供しないオブジェクトも不変です。
不変オブジェクトは、作成後に変更することはできません。もちろん、最終的にそれを達成するのに役立ちます。あなたはそれらが決して変更されないことを保証します。 [〜#〜] but [〜#〜]オブジェクト内に最終的な配列がある場合はどうなりますか?もちろん、参照は変更できませんが、要素は変更できます。ここでも私が出したほぼ同じ質問を見てください:
オブジェクトをfinal
として宣言するだけでは、オブジェクトは本質的に不変になりません。この例を見てみましょう クラス :
import Java.util.Date;
/**
* Planet is an immutable class, since there is no way to change
* its state after construction.
*/
public final class Planet {
public Planet (double aMass, String aName, Date aDateOfDiscovery) {
fMass = aMass;
fName = aName;
//make a private copy of aDateOfDiscovery
//this is the only way to keep the fDateOfDiscovery
//field private, and shields this class from any changes that
//the caller may make to the original aDateOfDiscovery object
fDateOfDiscovery = new Date(aDateOfDiscovery.getTime());
}
/**
* Returns a primitive value.
*
* The caller can do whatever they want with the return value, without
* affecting the internals of this class. Why? Because this is a primitive
* value. The caller sees its "own" double that simply has the
* same value as fMass.
*/
public double getMass() {
return fMass;
}
/**
* Returns an immutable object.
*
* The caller gets a direct reference to the internal field. But this is not
* dangerous, since String is immutable and cannot be changed.
*/
public String getName() {
return fName;
}
// /**
// * Returns a mutable object - likely bad style.
// *
// * The caller gets a direct reference to the internal field. This is usually dangerous,
// * since the Date object state can be changed both by this class and its caller.
// * That is, this class is no longer in complete control of fDate.
// */
// public Date getDateOfDiscovery() {
// return fDateOfDiscovery;
// }
/**
* Returns a mutable object - good style.
*
* Returns a defensive copy of the field.
* The caller of this method can do anything they want with the
* returned Date object, without affecting the internals of this
* class in any way. Why? Because they do not have a reference to
* fDate. Rather, they are playing with a second Date that initially has the
* same data as fDate.
*/
public Date getDateOfDiscovery() {
return new Date(fDateOfDiscovery.getTime());
}
// PRIVATE //
/**
* Final primitive data is always immutable.
*/
private final double fMass;
/**
* An immutable object field. (String objects never change state.)
*/
private final String fName;
/**
* A mutable object field. In this case, the state of this mutable field
* is to be changed only by this class. (In other cases, it makes perfect
* sense to allow the state of a field to be changed outside the native
* class; this is the case when a field acts as a "pointer" to an object
* created elsewhere.)
*/
private final Date fDateOfDiscovery;
}
文字列クラスは不変ですが、プロパティハッシュは最終ではありません
まあそれは可能ですが、いくつかのルール/制限があって、それは変更可能なプロパティ/フィールドへのアクセスであり、アクセスするたびに同じ結果を提供する必要があります。
文字列クラスでは、文字列が作成されても変更されない文字の最終配列で実際に計算されたハッシュコード。したがって、不変クラスには可変フィールド/プロパティを含めることができますが、フィールド/プロパティへのアクセスがアクセスされるたびに同じ結果を生成することを確認する必要があります。
あなたの質問に答えるために、すべてのフィールドを不変クラスでfinalにする必要はありません。
詳細については、こちらをご覧ください[ブログ]: http://javaunturnedtopics.blogspot.in/2016/07/string-is-immutable-and-property-hash.html
番号。
たとえば、Java.lang.String
の実装を参照してください。文字列はJavaでは不変ですが、フィールドhash
はfinalではありません(最初にhashCode
が呼び出されてからキャッシュされるときに遅延計算されます)。ただし、hash
は、計算されるたびに同じであるデフォルト以外の値を1つしか取ることができないため、これは機能します。
必要ではありませんが、メンバーを最終ではなくプライベートにして、コンストラクター以外では変更しないことで、同じ機能を実現できます。それらにセッターメソッドを提供しないでください。変更可能なオブジェクトの場合は、そのメンバーの参照をリークしないでください。
参照変数をfinalにすることを忘れないでください。参照変数が別の値に再割り当てされないようにするだけですが、その参照変数が指すオブジェクトの個々のプロパティを変更できます。これがポイントの一つです。