Özellikle Java ile ilgili olarak hiçbir şey ifade etmiyor.
Bir sınıf değişmezi, başka bir kod ne yaparsa yapsın, her zaman bir sınıfın tüm örneklerini tutan bir özelliktir.
Örneğin,
class X {
final Y y = new Y();
}
X, bir yözellik olduğuna dair sınıf değişmezine sahiptir ve hiçbir zaman yoktur nullve bir tür değerine sahiptir Y.
class Counter {
private int x;
public int count() { return x++; }
}
Bu, iki önemli değişmezi korumayı başaramaz:
- Bu
count, olası yetersizlik nedeniyle asla negatif bir değer döndürmez.
- Bu çağrılar
countkesinlikle monoton bir şekilde artıyor.
Değiştirilmiş sınıf, bu iki değişmezi korur.
class Counter {
private int x;
public synchronized int count() {
if (x == Integer.MAX_VALUE) { throw new IllegalStateException(); }
return x++;
}
}
... ancak counther zaman normal şekilde başarılı olma çağrısı yapan değişmezi koruyamaz (TCB ihlalleri † ), çünkü countbir istisna atabilir veya kilitli bir iş parçacığının sayacın monitörüne sahip olması durumunda engelleyebilir.
Sınıfları olan her dil, bazı sınıf değişmezlerini korumayı kolaylaştırırken bazılarını korumayı kolaylaştırır. Java bir istisna değildir:
- Java sınıfları sürekli olarak özelliklere ve yöntemlere sahiptir veya yoktur, bu nedenle arayüz değişmezlerinin bakımı kolaydır.
- Java sınıfları
privatealanlarını koruyabilir , bu nedenle özel verilere dayanan değişmezlerin bakımı kolaydır.
- Java sınıfları nihai olabilir, bu nedenle kötü amaçlı bir alt sınıf oluşturarak değişmezi ihlal eden hiçbir kodun olmamasına dayanan değişmezler korunabilir.
- Java,
nulldeğerlerin birçok şekilde gizlice girmesine izin verir , bu nedenle "gerçek bir değere sahip" değişmezlerini korumak zordur.
- Java'nın evreleri vardır, bu, senkronize olmayan sınıfların, birlikte gerçekleşen bir iş parçacığındaki sıralı işlemlere dayanan değişmezleri korumada sorun yaşadığı anlamına gelir.
- Java, "p özelliğine sahip bir sonuç döndürür veya sonuç döndürmez" gibi değişmezleri korumayı kolaylaştıran ancak "her zaman bir sonuç döndürür" gibi değişmezleri sürdürmeyi zorlaştıran istisnalara sahiptir.
† - Bir dışsallık veya TCB ihlali , bir sistem tasarımcısının iyimser bir şekilde olmayacağını varsaydığı bir olaydır.
Tipik olarak, temel donanımın, üzerlerine inşa edilen yüksek seviyeli dillerin özellikleri hakkında konuşurken reklamı yapıldığı gibi çalıştığına ve değişmezlerin sahip olduğu argümanlarımızın şu olasılıkları hesaba katmadığına güveniyoruz:
- Bir program kodun yapamayacağı şekilde çalışırken yerel değişkenleri değiştirmek için hata ayıklama kancalarını kullanan bir programcı.
- Akranlarınız, arama tablolarını
setAccessibledeğiştirmek için yansıma kullanmaz private.
- Loki, işlemcinizin iki sayıyı yanlış karşılaştırmasına neden olan fiziği değiştiriyor.
Bazı sistemler için TCB'miz sistemin yalnızca parçalarını içerebilir, bu nedenle şunu varsaymayabiliriz:
- Bir yönetici veya ayrıcalıklı bir arka plan programı JVM sürecimizi öldürmez,
... ancak şunu varsayabiliriz:
- Güvenilir bir işlem dosya sistemini kontrol edebiliriz.
Bir sistem ne kadar yüksek seviyeli olursa, TCB'si tipik olarak o kadar büyüktür, ancak TCB'nizden ne kadar güvenilmez şeyler elde ederseniz, değişmezlerinizin tutma olasılığı o kadar artar ve uzun vadede sisteminiz o kadar güvenilir olur.