Nie ma to żadnego szczególnego znaczenia w odniesieniu do języka Java.
Niezmiennik klasy to po prostu właściwość, która zachowuje się dla wszystkich instancji klasy, zawsze, bez względu na to, co robi inny kod.
Na przykład,
class X {
final Y y = new Y();
}
X ma niezmienną klasę, że istnieje ywłaściwość i nigdy nulljej nie ma i ma wartość typu Y.
class Counter {
private int x;
public int count() { return x++; }
}
nie zachowuje dwóch ważnych niezmienników
- To
countnigdy nie zwraca wartości ujemnej z powodu możliwego niedomiaru.
- Te wezwania
countsą ściśle monotoniczne.
Zmodyfikowana klasa zachowuje te dwa niezmienniki.
class Counter {
private int x;
public synchronized int count() {
if (x == Integer.MAX_VALUE) { throw new IllegalStateException(); }
return x++;
}
}
ale nie zachowuje niezmiennika, który wywołania countzawsze kończą się normalnym powodzeniem (brak naruszeń TCB † ), ponieważ countmoże zgłosić wyjątek lub może zablokować, jeśli wątek z zakleszczeniem jest właścicielem monitora licznika.
Każdy język z klasami ułatwia utrzymanie pewnych niezmienników klas, a innych nie. Java nie jest wyjątkiem:
- Klasy Java konsekwentnie mają właściwości i metody lub nie mają, więc niezmienniki interfejsu są łatwe w utrzymaniu.
- Klasy Java mogą chronić swoje
privatepola, więc niezmienniki, które opierają się na prywatnych danych, są łatwe w utrzymaniu.
- Klasy Java mogą być ostateczne, więc można zachować niezmienniki, które polegają na tym, że nie ma kodu naruszającego niezmiennik przez utworzenie złośliwej podklasy.
- Java pozwala
nullwartościom przemykać się na wiele sposobów, więc trudno jest zachować niezmienniki „ma rzeczywistą wartość”.
- Java ma wątki, co oznacza, że klasy, które nie są synchronizowane, mają problemy z utrzymaniem niezmienników, które polegają na sekwencyjnych operacjach w wątku, które są wykonywane razem.
- Java ma wyjątki, które ułatwiają utrzymanie niezmienników, takich jak „zwraca wynik z właściwością p lub nie zwraca żadnego wyniku”, ale trudniej jest zachować niezmienniki, takie jak „zawsze zwraca wynik”.
† - Zewnętrzne lub naruszenie TCB to zdarzenie, które projektant systemów optymistycznie zakłada, że nie nastąpi.
Zwykle po prostu ufamy, że podstawowy sprzęt działa zgodnie z reklamą, gdy mówimy o właściwościach języków wysokiego poziomu zbudowanych na nich, a nasze argumenty, które utrzymują niezmienniki, nie uwzględniają możliwości:
- Programista używający punktów zaczepienia do debugowania do zmiany lokalnych zmiennych, gdy program działa w sposób, którego kod nie może.
- Twoi koledzy nie używają odbicia z
setAccessibledo modyfikowania privatetabel przeglądowych.
- Loki zmienia fizykę, powodując, że twój procesor nieprawidłowo porównuje dwie liczby.
W przypadku niektórych systemów nasza TCB może zawierać tylko części systemu, więc możemy tego nie zakładać
- Administrator lub uprzywilejowany demon nie zabije naszego procesu JVM,
ale możemy to założyć
- Możemy przejść do niezawodnego transakcyjnego systemu plików.
Im system wyższego poziomu, tym zwykle jest większy jego TCB, ale im bardziej zawodne rzeczy można uzyskać z TCB, tym większe jest prawdopodobieństwo, że niezmienniki się utrzymają i tym bardziej niezawodny będzie system w dłuższej perspektywie.