Aula 9: Igualdade entre objetos, Cópia de objetos e Visões

Transcrição

1 Aula 9: Igualdade entre objetos, Cópia de objetos e Visões 9.1 O Contrato da Classe Object Toda classe estende a classe Object e, portanto, herda também todos os seus métodos. Dois destes métodos são particularmente importantes, pois geram conseqüências em todos os programas. O método para teste de igualdade: public boolean equals (Object o) e o método para geração de código hash: public int hashcode () Como quaisquer outros métodos de uma superclasse, estes métodos podem ser sobrepostos. Veremos em uma aula próxima, sobre tipagem, que uma subclasse deveria ser um subtipo. Isto significa que ela deveria se comportar de acordo com a especificação da superclasse, de forma que um objeto da subclasse possa ser utilizado em um contexto no qual um objeto da superclasse é esperado, funcionando apropriadamente. A especificação da classe Object é um tanto abstrata e pode ser considerada confusa. Mas a não conformidade com sua especificação pode ocasionar terríveis conseqüências, resultando em bugs complexos e obscuros. Ainda pior, se você não compreender esta especificação e suas ramificações, você poderá estar introduzindo falhas no seu código, falhas profundas e difíceis de serem eliminadas sem um trabalho duro. A especificação da classe Object é tão importante que muitas vezes é referenciada como O Contrato da classe Object, ou contrato de objeto. O contrato pode ser encontrado nas especificações dos métodos equals e hashcode na documentação da API Java. Onde é estabelecido o seguinte: equals deve estabelecer uma relação de equivalência - isto é, uma relação que é reflexiva, simétrica e transitiva; equals deve ser consistente: repetidas chamadas ao método devem gerar o mesmo resultado, a não ser quando os argumentos são modificados; para uma referência não nula x, x.equals(null) deve retornar false; hashcode deve produzir o mesmo resultado para dois objetos considerados iguais pelo método equals; 99

2 9.2 Propriedades de Igualdade Vamos olhar primeiro nas propriedades do método equals. Serreflexivo significa que um dado objeto será sempre igual a si mesmo; simetria significa que quando a equals b, b equals a; transitividade significa que quando a equals b e b equals c, a equals c. Estas propriedades podem parecer óbvias, e de fato são. Mas se elas não forem válidas, é difícil imaginar como o método equals poderia ser utilizado: seria preciso preocupar-se com a correta escrita do método: a.equals(b) ou b.equals(a), por exemplo, caso a simetria não fosse uma propriedade válida. Mas menos óbvio, no entanto, é o quão fácil essas propriedades podem ser quebradas inadvertidamente. O seguinte exemplo (extraído do excelente Effective Java: Programming Language Guide, de Joshua Bloch's, um dos textos recomendados pelo curso) mostra como a simetria e a transitividade podem ser quebradas quando utilizamos herança. Considere uma simples classe que implementa um ponto bi-dimensional: public class Point { private final int x; private final int y; public Point (int x, int y) { this.x = x; this.y = y; public boolean equals (Object o) { if (!(o instanceof Point)) return false; Point p = (Point) o; return p.x == x && p.y == y; Agora considere que adicionamos a noção de cor: public class ColourPoint extends Point { private Colour colour; public ColourPoint (int x, int y, Colour colour) { 100

3 super (x, y); this.colour = colour; Como deve ser o método equals da classe ColourPoint? Poderíamos apenas herdar o método equals de Point, mas dessa forma dois objetos ColourPoint seriam considerados iguais mesmo que tivessem cores diferentes. Poderíamos sobrepor o método da seguinte forma: public boolean equals (Object o) { if (!(o instanceof ColourPoint)) return false; ColourPoint cp = (ColourPoint) o; return super.equals (o) && cp.colour.equals(colour); Este método, aparentemente inofensivo, viola a exigência da simetria. Para ver o porquê, considere um ponto Point e um ponto colorido ColourPoint: Point p = new Point (1, 2); ColourPoint cp = new ColourPoint (1, 2, Colour.RED); Agora p.equals(cp) retorna true, mas cp.equals(p) retorna false! O problema é que estas duas expressões utilizam diferentes métodos equals: a primeira utiliza o método da classe Point, que ignora cor, e o segundo utiliza o método da classe ColourPoint. Poderíamos tentar consertar este problema fazendo com que o método da classe ColourPoint ignore a cor quando a comparação é realizada com um ponto que não é colorido: public boolean equals (Object o) { if (!(o instanceof Point)) return false; // se o é um Point normal, utilize a comparação sem considerar cor if (!(o instanceof ColourPoint)) return o.equals (this); ColourPoint cp = (ColourPoint) o; return super.equals (o) && cp.colour.equals (colour); 101

4 O que resolve o problema da simetria, mas agora temos um problema de transitividade! Para ver o porquê, considere a construção destes pontos: ColourPoint p1 = new ColourPoint (1, 2, Colour.RED); Point p2 = new Point (1, 2); ColourPoint p3 = new ColourPoint (1, 2, Colour.BLUE); As chamadas p1.equals(p2) e p2.equals(p3) irão ambas retornar true, mas p1.equals(p3) irá retornar false. Desta forma parece que não há solução para o problema: trata-se de um problema fundamental da utilização de herança. Não se pode escrever um bom método equals para ColourPoint, casoesta classe seja herdeira de Point. No entanto, se você implementar ColourPoint utilizando Point em sua representação, de maneira que um ColourPoint não seja mais tratado como um Point, o problema desaparece. Veja o livro de Bloch para mais detalhes. O livro de Bloch também dá boas dicas sobre como escrever um bom método equals, apontando alguns erros muito comuns. Por exemplo, o que acontece se você escreve alguma coisa parecida com isto: public boolean equals (Point p) Isto é, utilizando um outro tipo que não Object na declaração do método equals? 9.3 Hashing Para compreender a parte do contrato de objeto relacionada ao método hashcode, você deverá saber alguma coisa a respeito de como uma tabela hash funciona. As tabelas hash são uma invenção fantástica - uma das melhores idéias da ciência da computação. Uma tabela hash é uma representação de um mapeamento: um tipo abstrato de dado que mapeia chaves para valores. As tabelas hash oferecem tempo constante de busca e, portanto, possuem um desempenho melhor do que as árvores ou listas. As chaves não precisam estar ordenadas, ou possuírem qualquer propriedade particular, exceto oferecerem os métodos equals e hashcode. Agora mostraremos como uma tabela hash funciona. Ela possui um array inicialisado com um tamanho correspondente ao número de elementos que esperamos inserir. Quando uma chave e um valor são apresentados para inserção, computamos o valor hash (ou código hash) da chave, e 102

5 convertermos este código para um índice dentro do intervalo abrangido pelo array (por exemplo, através da operação módulo de divisão). O valor, então, é inserido naquele índice. A invariante rep de uma tabela hash inclui a restrição fundamental de que as chaves devem ser inseridas nas posições determinadas pelos seus respectivos códigos hash. Veremos mais adiante por que isso é importante. Os códigos hash são projetados de forma que as chaves sejam distribuídas igualmente ao longo dos índices. Mas, ocasionalmente ocorrem conflitos, e duas chaves são colocadas no mesmo índice. Então, ao invés de armazenar um único valor em um índice, a tabela hash armazena em cada posição de seu índice uma lista de pares chave/valor (normalmente denominados 'hash buckets'). Durante a inserção, insere-se um destes pares na lista correspondente à posição determinada pelo código hash. Durante a operação de busca, aplica-se a função hash sobre o elemento de busca para que se recupere seu código hash, encontra-se a posição correta no array, e examinam-se cada um dos pares alocados na lista daquela posição até que se encontre a chave procurada. Agora deve estar claro o porquê da exigência de que objetos iguais tenham o mesmo código hash. Se dois objetos que são iguais possuem códigos diferentes, eles podem ser colocados em posições diferentes. Então, se tentarmos fazer uma busca utilizando a chave utilizada na operação de inserção do par chave/valor, a busca pode falhar. Uma maneira simples e drástica para se garantir que o contrato de objeto é satisfeito pelo método hashcode, é fazer com que este método retorne sempre um valor constante, de maneira que todo objeto tenha o mesmo código hash. Esta medida satisfaz o contrato de objeto, mas resultaria em um desastre de performance, pois toda chave seria armazenada na mesma posição, e toda busca seria realizada linearmente ao longo de uma lista. A maneira padrão de se construir um código hash mais adequado, e que ainda satisfaz o contrato, é computar o código hash para cada componente (propriedade do objeto) utilizado na determinação de igualdade do objeto. Normalmente, procede-se chamando o método hashcode de cada componente, combinando cada código conseguido através de algumas operações aritméticas. Refira-se ao livro de Bloch para mais detalhes. Ainda mais crucial, perceba que se você não sobrepor o método hashcode, você estará utilizando a versão do método da classe Object, que é baseada no endereço do objeto. Caso você tenha sobreposto o método equals, é quase certeza que você violou o contrato. Então, como uma regra geral: Sempre sobreponha o método hashcode quando você sobrepor o método equals. 103

6 Esse é um dos aforismos de Bloch. Todo o livro é uma coleção de aforismos como este, cada um dos quais explicado e ilustrado. Ano passado, um estudante dedicou horas tentando descobrir um bug em um projeto que foi escrito com um pequeno erro: ao invés de hashcode, foi utilizado o termo hashcode. Como resultado, foi criado um método que não sobrepôs o método hashcode da classe Object, fazendo com que coisas estranhas acontecessem. (o Java é sensível ao caso). Esta é uma outra razão para se evitar a utilização do recurso de herança Copiando Objetos Muitas vezes surge a necessidade de se fazer a cópia de um objeto. Por exemplo, você pode querer realizar uma computação que altera um objeto, mas deseja que outros objetos que já fazem referência a este objeto não sejam afetados. Ou, em um outro caso, você pode ter um objeto protótipo a partir do qual você quer criar uma coleção de objetos que diferem sutilmente, sendo conveniente fazer cópias deste protótipo para modificá-las. As pessoas às vezes falam a respeito de cópias 'rasas' e de cópias 'profundas'. Uma cópia rasa de um objeto é conseguida criando-se um novo objeto cujos campos apontam para os mesmos objetos para os quais o objeto original apontava. Uma cópia profunda é conseguida criando-se, também, um novo objeto para cada um dos objetos apontados pelos campos do objeto original e, talvez, para os objetos para os quais estes objetos apontam, e assim por diante. Como a cópia deve ser feita? Se você foi estudioso e consultou a API Java, você pode supor que será necessário utilizar o método clone da classe Object, junto com a interface Cloneable. Istoé tentador, pois Cloneable é um tipo especial de interface que adiciona funcionalidades mágicas a uma classe. Infelizmente, no entanto, o projeto desta parte do Java não está muito correta, sendo muito difícil utilizá-la corretamente. Portanto, eu recomendo que você não a utilize, a menos que seja obrigado (por exemplo, quando o código que você está utilizando requer que se implemente Cloneable, ou porque seu gerente não participou do curso 6170). Consulte o livro de Bloch para uma interessante discussão dos problemas relacionados. Você pode achar que é bom declarar um método desta forma: class Point { Point copy () { 104

7 Preste atenção ao tipo de retorno: a cópia de um Point deve resultar em um Point. Mas em uma subclasse, você gostaria que o método copy retornasse umobjeto da subclasse: class ColourPoint extends Point { ColourPoint copy () { Infelizmente, isto não é permitido em Java. Você não pode alterar o tipo de retorno de um método quando sobrepô-lo em uma subclasse. E a sobrecarga de nomes de métodos permite apenas a alteração dos tipos dos argumentos. Portanto, você seria forçado a declarar ambos os métodos da seguinte forma: Object copy () Isto é um incômodo, pois será necessário fazer uma operação de downcast paraquesepossa trabalhar com o tipo correto. Mas este recurso funciona, e algumas vezes é a coisa certa a se fazer. Existem duas outras formas de se fazer uma cópia. Uma delas é utilizar um método estático conhecido como método 'factory', ou método de fabricação, pois cria novos objetos: public static Point newpoint (Point p) A outra forma é fornecer construtores adicionais, normalmente denominados 'copy constructors', ou 'construtores de cópia'. public Point (Point p) Ambas as formas funcionam muito bem, embora não sejam perfeitas. Você não pode colocar métodos estáticos ou construtores em uma interface, portanto, essas alternativas não são perfeitas quando você quer promover funcionalidades genéricas. A abordagem do construtor de cópia é amplamente utilizada na API do Java. Uma característica interessante dessa abordagem é que ela permite que o cliente escolha a classe do objeto a ser criado. O argumento para o construtor de 105

8 cópia é muitas vezes declarado como tendo o tipo de uma interface, de maneira que você possa passar para o construtor qualquer tipo de objeto que implemente a interface. Todas as classes de coleção do Java, por exemplo, fornecem um construtor de cópia que recebe um argumento do tipo Collection ou Map. Se você pretende criar um ArrayList apartirdeumlinkedlist l, por exemplo, seria preciso apenas chamar new ArrayList (l) 9.5 Igualdade de Elementos e igualdade de Containers Containers são objetos que, fundamentalmente, armazenam referências para outros elementos ou objetos. Por exemplo, os tipos List e derivados são containers. Quando dois objetos do tipo container são iguais? Se eles são imutáveis, eles devem ser iguais se contiverem os mesmos elementos. Por exemplo, duas strings devem ser iguais se elas contêm os mesmos caracteres (na mesma ordem). Se apenas mantivermos o método padrão de igualdade da classe Object, uma string inserida através do teclado, por exemplo, nunca seria igual a uma string que está em uma lista ou uma tabela, pois seria um novo objeto string (uma outra instância) e, portanto, não seria o mesmo objeto. De fato, é exatamente assim que o método equals é implementado na classe String do Java, e se você quer saber se duas strings s1 e s2 contêm a mesma seqüência de caracteres, você deverá escrever: s1.equals (s2) enão s1 == s2 A segunda linha de código do exemplo acima irá retornar falso quando s1 e s2 representarem diferentes objetos string, mesmo que contenham a mesma seqüência de caracteres O Problema Chega de strings ou seqüências de caracteres. Vamos considerar agora as listas, que são seqüências de objetos arbitrários. As listas devem ser consideradas da mesma forma que as strings, de forma que duas listas são iguais se elas contiverem os mesmos elementos na mesma ordem? 106

9 Suponha que estou planejando uma festa na qual meus amigos irão se sentar em várias mesas diferentes, e que escrevi um programa para me ajudar a estabelecer o planejamento. Eu represento cada mesa como uma lista de amigos, e a festa inteira como um conjunto de listas do tipo HashSet. O programa se inicia criando listas vazias para as mesas e inserindo estas listas ao conjunto de mesas: List t1 = new LinkedList (); List t2 = new LinkedList (); Set s = new HashSet (); s.add (t1); s.add (t2); Em algum momento mais tarde, o programa irá adicionar amigos às várias listas; podendo, também, criar novas listas e substituir listas existentes no conjunto por estas novas listas. Finalmente, o programa realiza uma iteração sobre o conjunto de mesas imprimindo cada uma das listas. Este programa irá falhar, pois as inserções iniciais não surtirão o efeito esperado. Mesmo que as listas vazias representem conceitualmente mesas distintas, de acordo com o método equals de LinkedList, elas serão iguais. Pois a classe Set aplica o método equals sobre seus elementos afim de rejeitar duplicatas. Portanto, todas as inserções, menos a primeira, não surtirão nenhum efeito, pois todasaslistasvaziasserãoencaradascomoduplicatas. Como solucionar este problema? Você pode imaginar que Set deveria ter utilizado == para checar por duplicatas, ao invés de equals. Desta maneira, um objeto será considerado uma duplicata apenas seéexatamenteaqueleobjeto(amesmainstância)quejáestánoconjunto. É interessante observar que, embora resolva o problema acima, esta abordagem não funciona para strings; isto significa que após Set Set = new HashSet (); String lower = "hello"; String upper = "HELLO"; Set.add (lower.touppercase()); O testeset.contains(upper) iria retornar false, pois o método touppercase cria uma nova string. 107

10 9.5.2 A Solução de Liskov No texto de nosso curso, Liskov apresenta uma solução sistemática para o problema. Você deve fornecer dois métodos distintos: equals que retorna true quando dois objetos de uma classe possuem comportamento equivalente e, similar, que retorna true quando dois objetos podem ser observados como equivalentes. Aqui está a diferença. Dois objetos possuem comportamento equivalente senão existe uma seqüência de operações que possa distingüí-los. Nestes termos, as listas vazias t1 e t2 do exemplo acima não são equivalentes, pois se você inserir um elemento em uma delas, você pode observar que uma é alterada, mas a outra não. Mas duas strings distintas que contêm a mesma seqüência de caracteres são equivalentes no comportamento, pois você não pode modificá-las e, portanto, não pode descobrir que são objetos diferentes (estamos assumindo que você não pode utilizar == neste experimento). Dois objetos podem ser observados como equivalentes, ou seja, eles possuem uma equivalência observacional, se você não puder identificar a diferença entre eles utilizando operações do tipo observadoras (e não operações do tipo modificadoras). Nestes termos, as listas vazias t1 e t2 do exemplo acima são equivalentes, pois possuem mesmo tamanho, contêm os mesmos elementos, etc. Desta forma duas strings que contêm a mesma seqüência de caracteres são, também, equivalentes. Mostraremos agora como você pode codificar equals e similar. Para um tipo mutável, você simplesmente herda o método equals da classe Object, e escreve um método similar que realiza uma comparação campo a campo. Para um tipo imutável, você deve sobrepor o método equals com um método que realiza a comparação campo a campo, e deve fazer com que similar invoque equals de maneira que eles sejam o mesmo método (similar se torna umwrapper de equals). Esta solução, quando aplicada uniformemente, é de fácil compreensão e funciona bem. Mas nem sempre é ideal. Suponha que você queira escrever um código que utiliza o padrão de projeto Interning, que será visto na aula 12. Este padrão determina que se você possui referências a objetos estruturalmente idênticos, deve-se alterar sua estrutura de dados de forma que as referências para estes objetos apontem para exatamente a mesma instância do objeto, descartando as instâncias de maneira que reste apenas uma (o representante canônico). Isto é muitas vezes utilizado em compiladores; os objetos podem ser variáveis de programas, por exemplo, e você deseja que todas as referências para uma variável particular da árvore de sintaxe abstrata apontem para o mesmo objeto, assim, qualquer informação que você armazene a respeito desta variável (alterando o objeto) é efetivamente propagada para todos os locais onde esta variável aparece. 108

11 Para armazenar e controlar os objetos, você pode tentar utilizar uma tabela hash. Toda vez que você encontrar um novo objeto na estrutura de dados, você deve procurar este objeto na tabela para verificar se ele possui um representante canônico. Se possuir o representante, você deve substituir o objeto pelo seu representante; do contrário, se não houver um representante, você deve inserí-lo na tabela hash de forma que ele seja, ao mesmo tempo, chave e valor. Segundo a abordagem de Liskov, esta estratégia iria falhar, pois o teste de igualdade sobre as chaves nunca encontraria uma correspondência para objetos distintos que são estruturalmente equivalentes, pois o método equals de um objeto mutável só retorna true quando se trata, exatamente, do mesmo objeto A Abordagem Java Por razões como esta, o projetista da API de coleções do Java não seguiu esta abordagem. Não existe ummétodo similar, e o método equals refere-se à equivalência observacional. Este fato pode causar algumas conseqüências convenientes como, por exemplo, a tabela hash de armazenagem irá funcionar. Mas também possui algumas conseqüências infortúnias. O programa de planejamento de festa do exemplo da seção não irá funcionar, pois duas listas distintas vazias serão consideradas iguais, como já foi apontado. Na especificação da classe List do Java, duas listas são iguais não apenas se elas contêm os mesmos elementos na mesma ordem, mas apenas se elas contêm elementos iguais segundo o método equals, e na mesma ordem. Em outras palavras, o método equals é chamado recursivamente para todos os elementos armazenados. Para manter o contrato de objeto, o método hashcode também é chamado recursivamente sobre os elementos. O que ocasiona uma surpresa desagradável. O seguinte código, no qual uma lista é inserida em si mesma, irá falhar, pois nunca será concluído, ou seja, nunca irá terminar! List l = new LinkedList (); l.add (l); int h = l.hashcode (); Esta é a razão pela qual você irá encontrar avisos na documentação da API Java a respeito da inserção de objetos containers neles próprios, veja, por exemplo, este comentário da especificação da classe List: 109

12 Nota: ao passo que é permitido que as listas contenham a si próprias como elementos, é feito um aviso para tomada de extrema cautela: os métodos equals e hashcode não mais estão bem definidos neste tipo de lista. Existem outras conseqüências, ainda mais delicadas, decorrentes da abordagem Java. São conseqüências a respeito da exposição de representação. Como será explicado mais adiante. Este fato lhe deixa com duas opções, ambas as quais são aceitas pelas idéias do curso 6170: Você pode seguir a abordagem Java, na qual você terá os benefícios de sua conveniência, mas terá que lidar com as complicações que podem surgir. Alternativamente, você pode seguir a abordagem de Liskov, mas nesse caso você terá que descobrir como incorporar as classes de coleções do Java no seu código (com LinkedList e HashSet). Em geral, quando você tem quem incorporar uma classe da qual o método equals segue uma abordagem diferente do programa como um todo, você pode escrever um wrapper paraaclassea ser incorporada para substituir o método equals por um mais adequado. O texto do curso dá um exemplo de como fazer isso. 9.6 Exposição de Rep Vamos rever o exemplo da exposição de rep com o qual encerramos a última aula. Lá imaginamos uma variante de LinkedList para representar seqüências sem duplicatas. A operação add foi definida como possuindo uma especificação que determina que um elemento só é adicionado caso este elemento não seja uma duplicata, sendo que o código do método add deve realizar esta checagem. void add (Object o) { if (contains (o)) return; else // adiciona o elemento Devemos registrar, no topo do arquivo, a determinação da invariante rep, isto é, um aviso dizendo que a lista não contém duplicatas: 110

13 A lista não contém duplicatas. Ou seja, não existem duas entradas (objetos Entry) distintas e1 e e2 tais que e1.element.equals (e2.element). Para verificamos que esta propriedade é preservada, devemos nos certificar que todo método que adiciona um elemento, primeiro realiza uma checagem. Infelizmente, esta não é uma boa idéia. Veja o que acontece se construímos uma lista de listas e alteramos um dos elementos lista: List x = new LinkedList (); List y = new LinkedList (); Object o = new Object (); x.add (o); List p = new LinkedList (); p.add (x); p.add (y); x.remove (o); Após esta seqüência de código, a invariante rep de p é quebrada. O problema é que a alteração em x o torna igual a y, pois ambos são listas vazias. O que está acontecendo aqui? O contorno de invariante que passamos ao redor da representação inclui a classe do elemento, pois a invariante rep depende de uma propriedade do elemento (veja a figura). Perceba que este problema não teria surgido se a igualdade tivesse sido determinada pela abordagem de Liskov, pois dois elementos mutáveis seriam iguais apenas se eles fossem exatamente o mesmo objeto: o contorno se estende apenas até a referência do elemento, e não até o elemento propriamente dito. 111

14 9.6.1 Alterando Chaves Hash Um exemplo mais comum e com maior ocorrência deste fenômeno ocorre com chaves hash. Se você alterar um objeto depois que ele foi inserido como uma chave de uma tabela hash, pode ocorrer que seu código hash seja alterado. Como resultado, a invariante rep crucial da tabela hash - aquela que determina que as chaves estão armazenadas nas posições especificadas pelos seus respectivos códigos hash - é quebrada. Aqui temos um exemplo. Um conjunto hash pode ser entendido como um conjunto implementado sobre uma tabela hash: imagine este conjunto como uma tabela hash com chaves, mas nenhum valor. Se inserirmos uma lista vazia no conjunto hash e, então, inserirmos um elemento na lista da seguinte forma: Set s = new HashSet (); List x = new LinkedList (); s.add (x); x.add (new Object ()); Uma chamada subseqüente s.contains(x) provavelmente irá retornar false. Se você considera isto aceitável, considere o fato de que agora não existe nenhum valor x para o qual s.contains(x) retorna true, mesmo que s.size() retorne 1! Novamente, o problema é exposição de representação: o contorno ao redor da tabela hash inclui as chaves. A lição que tiramos disso é: ou você segue a abordagem de Liskov, que utiliza um wrapper para sobrepor o método equals da lista do Java, ou certifica-se de que nunca irá alterar a chaves hash. Do contrário você pode permitir qualquer alteração de um elemento, mas estará correndo o risco de quebrar a invariante rep do container no qual o elemento está inserido. Esta é a razão pela qual você verá comentários como este na especificação da API Java: Nota: muito cuidado deve ser tomado com objetos mutáveis que são utilizados como elementos de um conjunto. O comportamento de um conjunto torna-se indefinido caso o valor de um objeto seja alterado de maneira que a alteração afete as comparações de igualdade enquanto este objeto for um elemento do conjunto. Um caso especial de proibição é: não é permitido que um conjunto contenha a si mesmo como um elemento. 112

15 9.7 Visões Uma prática cada vez mais comum na programação orientada a objetos é ter-se objetos distintos que oferecem diferentes tipos de acesso para a mesma estrutura de dados subjacente. Tais objetos são denominados views, ou visões. Normalmente um objeto é chamado de primário, e um outro de secundário. O objeto primário é chamado de objeto 'underlying', ou subjacente; e o objeto secundário é chamado de 'view', ou visão. Estamos acostumados com a utilização de aliasing, isto é, existem duas (ou mais) referências com nomes distintos para o mesmo objeto, de forma que uma alteração no objeto acessado via uma das referências aparece como uma alteração para a outra referência: List x = new LinkedList (); List y = x; x.add (o); // altera y também As visões são problemáticas, pois elas envolvem uma forma delicada de aliasing, na qual os dois objetos possuem tipos distintos. Nós vimos um exemplo destes com iteradores, cujo método remove de um iterador remove da coleção subjacente o último elemento inserido: List x = new LinkedList (); Iterator i = x.iterator (); while (i.hasnext ()) { Object o = i.next (); i.remove (); //altera x também Um iterador pode ser considerado como uma visão da coleção subjacente. Aqui temos dois outros exemplos de visões da API de coleções do Java. Para que se consiga um método keyset que retorna um conjunto de chaves de um objeto Map, é exigido que se implemente a interface Map. Este conjunto é uma visão; pois se o objeto Map subjacente for alterado, o conjunto retornado por keyset será alterado de forma semelhante. Diferente de um iterador, esta visão e o objeto subjacente podem, ambos, serem modificados; deletar-se uma chave do conjunto irá fazer com que a chave e seu valor sejam deletados do objeto Map. O conjunto não suporta uma operação add, pois não haveria sentido em se 113

16 adicionar uma chave sem um valor. (isto, por acaso, é a razão pela qual os métodos add e remove são métodos opcionais da interface Set). A classe List possui um método sublist que retorna uma visão de parte da lista. A visão retornada pelo método sublist pode ser usada para se acessar a lista com o auxílio de um offset, eliminando a necessidade de operações explícitas sobre o intervalo de índices. Qualquer método sobre o intervalo de índices da lista subjacente, e que espera uma lista como argumento, pode ser utilizado passando-se apenas uma visão na forma de uma sublista, ao invés da lista toda. Por exemplo, o seguinte código remove um intervalo de elementos de uma lista: List.subList(from, to).clear(); Idealmente, uma visão e seu objeto subjacente deveriam ser, ambos, modificáveis com os efeitos decorrentes das modificações sendo, perfeitamente, propagados entre os dois. Infelizmente, isto não é sempre possível, muitas visões determinam restrições sobre as quais, alguns tipos de alterações são impossíveis. Um iterador, por exemplo, se torna inválido se a coleção subjacente for modificada durante a iteração. Uma sublista é invalidada por certas alterações estruturais ocorridas na lista subjacente. As coisas ficam ainda mais complicadas quando existem diversas visões do mesmo objeto. Por exemplo, se você tem dois iteradores simultaneamente sobre a mesma coleção subjacente, uma modificação sobre um iterador (através de uma chamada ao método remove) irá invalidar o outro iterador (mas não a coleção). 9.8 Resumo Os tópicos a respeito de igualdade entre objetos, cópia de objetos e visões demonstram o poder da programação orientada a objetos, mas também demonstram suas armadilhas. Você deve utilizar um tratamento sistemático e uniforme durante a utilização de igualdade, durante a utilização de hashing e durante as operações de cópia em qualquer programa que você escreva. As visões são um mecanismo muito útil, mas devem ser utilizadas cuidadosamente. A construção de um modelo de objeto para o seu programa é outra prática útil, pois o modelo irá lembrar você dos locais onde ocorre compartilhamento fazendo com que você examine cada caso com muito cuidado. 114