Це не означає нічого конкретно стосовно Java.
Інваріант класу - це просто властивість, яка виконується для всіх екземплярів класу, завжди, незалежно від того, що робить інший код.
Наприклад,
class X {
final Y y = new Y();
}
X має інваріант класу, що існує yвластивість, і воно ніколи не є, nullі воно має значення типу Y.
class Counter {
private int x;
public int count() { return x++; }
}
не підтримує двох важливих інваріантів
- Це
countніколи не повертає від’ємне значення через можливий недолік.
- Це заклики до
countсуворо монотонно зростають.
Модифікований клас зберігає ці два інваріанти.
class Counter {
private int x;
public synchronized int count() {
if (x == Integer.MAX_VALUE) { throw new IllegalStateException(); }
return x++;
}
}
але не вдається зберегти інваріант, який вимагає countзавжди нормального успіху (відсутні TCB-порушення † ), оскільки countможе викликати виняток або може заблокувати, якщо заблокований потік володіє монітором лічильника.
Кожна мова з класами полегшує підтримку одних інваріантів класів, а інших - не. Java не є винятком:
- Класи Java постійно мають або не мають властивостей і методів, тому інваріанти інтерфейсу прості в обслуговуванні.
- Класи Java можуть захищати свої
privateполя, тому інваріанти, які покладаються на приватні дані, легко підтримувати.
- Класи Java можуть бути остаточними, тому інваріанти, які покладаються на відсутність коду, який порушує інваріант, створюючи шкідливий підклас, можна підтримувати.
- Java дозволяє
nullцінностям підбиратись різними способами, тому важко підтримувати інваріанти "має справжнє значення".
- Java має потоки, що означає, що класи, які не синхронізуються, мають проблеми з підтримкою інваріантів, які покладаються на послідовні операції в потоці, що відбуваються разом.
- Java має винятки, що полегшує підтримку інваріантів, таких як "повертає результат із властивістю p або не повертає результату", але важче підтримувати інваріанти, наприклад "завжди повертає результат".
† - Зовнішнє порушення або порушення TCB - це подія, яка, з оптимізмом припускає дизайнер систем, не відбудеться.
Зазвичай ми просто довіряємо, що основне обладнання працює так, як рекламується, коли мова йде про властивості мов високого рівня, побудованих на них, і наші аргументи, які дотримуються інваріанти, не враховують можливості:
- Програміст, який використовує хуки для налагодження для зміни локальних змінних, оскільки програма працює так, що код не може.
- Ваші однолітки не використовують відображення
setAccessibleдля зміни privateтаблиць пошуку.
- Локі змінює фізику, через що ваш процесор неправильно порівнює два числа.
Для деяких систем наш TCB може включати лише частини системи, тому ми можемо не припускати цього
- Адміністратор або привілейований демон не вб'є наш процес JVM,
але ми могли б припустити це
- Ми можемо перевірити надійну транзакційну файлову систему.
Чим система вищого рівня, тим більшим є її TCB, але чим більше ненадійних речей ви можете отримати з вашого TCB, тим більша ймовірність збереження ваших інваріантів, і тим надійнішою буде ваша система в довгостроковій перспективі.