不変オブジェクトはすべてのプロパティが である必要がありますfinal
か?
私によれば、そうではありません。しかし、私が正しいかどうかはわかりません。
不変オブジェクトはすべてのプロパティが である必要がありますfinal
か?
私によれば、そうではありません。しかし、私が正しいかどうかはわかりません。
不変オブジェクト (すべてのプロパティが final) と事実上不変オブジェクト (プロパティは final ではないが変更できない) の主な違いは、安全なパブリケーションです。
final フィールドの Java メモリ モデルによって提供される保証のおかげで、同期を追加することを心配することなく、マルチスレッド コンテキストで不変オブジェクトを安全に発行できます。
final フィールドを使用すると、プログラマーは同期なしでスレッドセーフな不変オブジェクトを実装することもできます。スレッド間で不変オブジェクトへの参照を渡すためにデータ競合が使用されている場合でも、スレッド セーフな不変オブジェクトはすべてのスレッドで不変と見なされます。これにより、不正または悪意のあるコードによる不変クラスの悪用に対する安全性が保証されます。不変性を保証するには、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 にすることをお勧めします。オブジェクトのすべてのプロパティが変更されないように保護されていない場合、オブジェクトが不変であるとは言えません。
ただし、プライベート プロパティのセッターが提供されていない場合、オブジェクトは不変でもあります。
単にオブジェクトを as として宣言するだけ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 ではありません
それは可能ですが、いくつかのルール/制限があり、可変プロパティ/フィールドへのアクセスは、アクセスするたびに同じ結果を提供する必要があります。
String クラスでは、最終的な文字配列で実際に計算されたハッシュコードは、String が構築された場合に変更されません。したがって、不変クラスには可変フィールド/プロパティを含めることができますが、フィールド/プロパティへのアクセスがアクセスされるたびに同じ結果を生成することを確認する必要があります。
あなたの質問に答えるために、不変クラスですべてのフィールドを final にすることは必須ではありません。
詳細については、[ブログ] を参照してください。