Non significa niente in particolare in riferimento a java.
Una classe invariante è semplicemente una proprietà che vale per tutte le istanze di una classe, sempre, indipendentemente da ciò che fa l'altro codice.
Per esempio,
class X {
final Y y = new Y();
}
X ha la classe invariante che esiste una yproprietà e non lo è mai nulle ha un valore di tipo Y.
class Counter {
private int x;
public int count() { return x++; }
}
non riesce a mantenere due importanti invarianti
- Non
countrestituisce mai un valore negativo a causa di un possibile underflow.
- Quelle chiamate a
countstanno aumentando rigorosamente monotonicamente.
La classe modificata conserva questi due invarianti.
class Counter {
private int x;
public synchronized int count() {
if (x == Integer.MAX_VALUE) { throw new IllegalStateException(); }
return x++;
}
}
ma non riesce a preservare l'invariante che chiama per countavere sempre successo normalmente (assente TCB-violazioni † ) perché countpotrebbe generare un'eccezione o potrebbe bloccarsi se un thread con deadlock possiede il monitor del contatore.
Ogni lingua con le classi rende facile mantenere alcune invarianti di classe ma non altre. Java non fa eccezione:
- Le classi Java hanno costantemente o non hanno proprietà e metodi, quindi le invarianti dell'interfaccia sono facili da mantenere.
- Le classi Java possono proteggere i loro
privatecampi, quindi le invarianti che si basano su dati privati sono facili da mantenere.
- Le classi Java possono essere finali, quindi è possibile mantenere invarianti che si basano sul fatto che non ci sia codice che violi un invariante creando una sottoclasse dannosa.
- Java consente ai
nullvalori di entrare di nascosto in molti modi, quindi è difficile mantenere invarianti "ha un valore reale".
- Java ha thread, il che significa che le classi che non si sincronizzano hanno problemi a mantenere invarianti che si basano su operazioni sequenziali in un thread che avvengono insieme.
- Java ha eccezioni che rendono facile mantenere invarianti come "restituisce un risultato con la proprietà pe non restituisce alcun risultato" ma più difficile mantenere invarianti come "restituisce sempre un risultato".
† - Una violazione di esternalità o TCB è un evento che un progettista di sistemi presume ottimisticamente non accadrà.
In genere ci fidiamo solo del fatto che l'hardware di base funzioni come pubblicizzato quando si parla di proprietà di linguaggi di alto livello costruiti su di essi, e le nostre argomentazioni che valgono le invarianti non tengono conto della possibilità di:
- Un programmatore che usa gli hook di debug per alterare le variabili locali mentre un programma viene eseguito in modi che il codice non può.
- I tuoi colleghi non usano la riflessione con
setAccessibleper modificare privatele tabelle di ricerca.
- Loki altera la fisica causando il confronto errato del processore tra due numeri.
Per alcuni sistemi il nostro TCB potrebbe includere solo parti del sistema, quindi potremmo non assumerlo
- Un amministratore o un demone privilegiato non ucciderà il nostro processo JVM,
ma potremmo presumere che
- Possiamo controllare un file system transazionale affidabile.
Più alto è un sistema, più grande è il suo TCB in genere, ma più cose inaffidabili puoi ottenere dal tuo TCB, più è probabile che i tuoi invarianti siano mantenuti e più affidabile sarà il tuo sistema a lungo termine.