Isso não significa nada em particular em referência a java.
Uma invariante de classe é simplesmente uma propriedade válida para todas as instâncias de uma classe, sempre, não importa o que outro código faça.
Por exemplo,
class X {
final Y y = new Y();
}
X tem a classe invariante de que existe uma ypropriedade e nunca é nulle tem um valor de tipo Y.
class Counter {
private int x;
public int count() { return x++; }
}
falha em manter dois invariantes importantes
- Isso
countnunca retorna um valor negativo devido a um possível estouro negativo.
- Essas chamadas
countestão aumentando estritamente monotonicamente.
A classe modificada preserva essas duas invariantes.
class Counter {
private int x;
public synchronized int count() {
if (x == Integer.MAX_VALUE) { throw new IllegalStateException(); }
return x++;
}
}
mas falha em preservar o invariante que chama para countsempre ter sucesso normalmente (violações de TCB ausentes † ) porque countpode lançar uma exceção ou pode bloquear se um thread em conflito possuir o monitor do contador.
Cada linguagem com classes torna mais fácil manter algumas invariantes de classe, mas não outras. Java não é exceção:
- As classes Java têm ou não têm propriedades e métodos consistentemente, portanto, as invariantes de interface são fáceis de manter.
- As classes Java podem proteger seus
private campos, portanto, invariantes que dependem de dados privados são fáceis de manter.
- As classes Java podem ser finais, portanto, as invariantes que dependem da inexistência de código que viole uma invariante criando uma subclasse maliciosa podem ser mantidas.
- Java permite que os
nullvalores se infiltrem de várias maneiras, por isso é difícil manter invariantes "tem um valor real".
- Java tem threads, o que significa que as classes que não sincronizam têm problemas para manter invariantes que dependem de operações sequenciais em uma thread acontecendo juntas.
- Java tem exceções que tornam fácil manter invariantes como "retorna um resultado com propriedade p ou não retorna nenhum resultado", mas é mais difícil manter invariantes como "sempre retorna um resultado".
† - Uma externalidade ou violação de TCB é um evento que um projetista de sistemas assume, de maneira otimista, que não acontecerá.
Normalmente, apenas confiamos que o hardware básico funciona conforme anunciado quando falamos sobre propriedades de linguagens de alto nível construídas sobre eles, e nossos argumentos que as invariantes mantêm não levam em consideração a possibilidade de:
- Um programador usando ganchos de depuração para alterar variáveis locais enquanto um programa é executado de maneiras que o código não pode.
- Seus pares não usam reflexão com
setAccessiblepara modificar privatetabelas de pesquisa.
- Loki alterando a física, fazendo com que seu processador compare incorretamente dois números.
Para alguns sistemas, nosso TCB pode incluir apenas partes do sistema, portanto, não podemos assumir que
- Um administrador ou daemon privilegiado não matará nosso processo JVM,
mas podemos supor que
- Podemos verificar um sistema de arquivos transacional confiável.
Quanto mais alto nível um sistema, maior normalmente é seu TCB, mas quanto mais coisas não confiáveis você pode obter de seu TCB, mais provável é que suas invariantes sejam retidas e mais confiável seu sistema será a longo prazo.