Esta é uma ótima pergunta. Eu gosto de ter a idéia de que, de todo o código escrito em java e rodando em milhões de computadores em todo o mundo, todo dia, 24 horas, cerca de metade do clock total deve ser desperdiçado fazendo nada além de cópias seguras de coleções. sendo retornado por funções. (E coleta de lixo essas coleções milissegundos após sua criação).
Uma porcentagem de programadores java está ciente da existência da família de métodos unmodifiableCollection() da classe Collections , mas mesmo entre eles muitos não se importam com isso.
E eu não posso culpá-los: uma interface que finge ser de leitura-escrita, mas vai lançar um UnsupportedOperationException se você cometer o erro de invocar qualquer um dos seus métodos de 'escrita' é uma coisa bastante malvada!
Agora, uma interface como Collection que estaria faltando os métodos add() , remove() e clear() não seria uma interface "ImmutableCollection"; seria uma interface "UnmodifiableCollection". Na verdade, nunca poderia haver uma interface "ImmutableCollection", porque a imutabilidade é uma natureza de uma implementação, não uma característica de uma interface. Eu sei, isso não é muito claro; deixe-me explicar.
Suponha que alguém lhe forneça essa interface de coleção somente leitura; é seguro passá-lo para outro segmento? Se você soubesse com certeza que isso representa uma coleção verdadeiramente imutável, a resposta seria "sim"; infelizmente, como é uma interface, você não sabe como ela é implementada, então a resposta tem que ser um não : por tudo o que você sabe, pode ser um não modificável (para você) a visão de uma coleção que é de fato mutável, (assim como o que você obtém com Collections.unmodifiableCollection() ,) então tentar ler a partir dela enquanto outra thread está modificando isso resultaria na leitura de dados corrompidos.
Então, o que você descreveu essencialmente é um conjunto de interfaces de coleção não "imutáveis", mas "não modificáveis". É importante entender que "Unmodifiable" simplesmente significa que quem quer que tenha uma referência a essa interface é impedido de modificar a coleção subjacente e ela é impedida simplesmente porque a interface não possui métodos de modificação, não porque a coleção subjacente é necessariamente imutável. A coleção subjacente pode muito bem ser mutável; você não tem conhecimento e não tem controle sobre isso.
Para ter coleções imutáveis, elas teriam que ser classes , não interfaces!
Essas aulas de coleção imutáveis teriam que ser finais, de modo que, quando você receber uma referência a essa coleção, tenha certeza de que ela se comportará como uma coleção imutável, não importa o que você ou qualquer outra pessoa que tenha uma referência a ela. isso pode fazer com isso.
Assim, para ter um conjunto completo de coleções em java (ou qualquer outro idioma imperativo declarativo), precisaríamos do seguinte:
-
Um conjunto de unmodifiable coleção interfaces .
-
Um conjunto de mutáveis coleções interfaces , estendendo as não modificáveis.
-
Um conjunto de mutáveis coleções classes implementando as interfaces mutáveis e, por extensão, também as interfaces não modificáveis.
-
Um conjunto de imutáveis coleções classes , implementando as interfaces não modificáveis, mas que geralmente são transmitidas como classes, para garantir a imutabilidade.
Implementei todos os itens acima para me divertir, e estou usando-os em projetos e eles funcionam como um encanto.
A razão pela qual eles não fazem parte do Java Runtime é provavelmente porque se pensava que isso seria muito / muito complexo / muito difícil de entender.
Pessoalmente, acho que o que descrevi acima não é suficiente; mais uma coisa que parece ser necessária é um conjunto de interfaces mutáveis & aulas para imutabilidade estrutural . (Que pode simplesmente ser chamado de "Rígido" porque o prefixo "StructurallyImmutable" é muito longo).