Este documento fornece uma introdução às coleções no Java, incluindo:
1) A importância de entender igualdade no Java para trabalhar com coleções;
2) Como sobrescrever corretamente o método equals para definir igualdade entre objetos;
3) Que também é necessário sobrescrever o método hashCode quando equals é sobrescrito.
Este documento apresenta as diretrizes para a política de desenvolvimento da coleção da Biblioteca Escolar do Agrupamento de Escolas “Finisterra”. A biblioteca escolar tem como missão apoiar o processo educativo, promovendo a literacia, o acesso à informação e o desenvolvimento de competências para a aprendizagem ao longo da vida. As suas principais linhas de ação incluem o apoio ao currículo, a leitura, projetos com a comunidade e a gestão da coleção. A política estabelece critérios de seleção,
Este documento estabelece as políticas e critérios para o desenvolvimento da coleção da biblioteca escolar EB 2,3 Marinhais. A biblioteca visa fornecer recursos que atendam às necessidades da comunidade escolar e promovam a aprendizagem, cultura e lazer. As aquisições devem garantir diversidade de pontos de vista e formatos de acordo com as necessidades dos usuários.
Preparando sua biblioteca_para_avalia_ca_o_do_mecIasp
Este documento fornece orientações sobre como preparar a biblioteca de uma instituição de ensino superior para a avaliação do Ministério da Educação brasileiro (MEC). Ele discute a importância de ter um acervo atualizado e adequado, recursos humanos qualificados, e instalações apropriadas para atender às necessidades dos usuários e aos critérios de avaliação do MEC.
O documento descreve as principais classes e interfaces do pacote java.util que representam coleções como listas, conjuntos e mapas. São descritas as interfaces Collection, List, Set e Map e suas subclasses mais comuns como ArrayList, LinkedList, HashSet, HashMap e TreeMap.
Este manual descreve os procedimentos da biblioteca escolar, incluindo a seleção, aquisição, tratamento técnico, catalogação, classificação, cotação e arrumação dos documentos. Também aborda a organização de dossiês temáticos, a biblioteca itinerante e empréstimos.
O documento discute os processos de seleção e aquisição de materiais para bibliotecas, incluindo conceitos, critérios de seleção, tipos de aquisição e considerações sobre o desenvolvimento de coleções.
O documento fornece dicas para avaliar atividades de pesquisa na Internet realizadas por alunos. Sugere combinar claramente com os alunos o resultado esperado, como compreensão de páginas, respostas a questões ou produção de texto. Também recomenda divulgar amplamente os critérios de avaliação e discuti-los com os alunos.
Avaliação de coleções do acervo do curso de Graduação de Espanholdaianadelima
Este documento resume um relatório sobre a avaliação da coleção de livros de quatro disciplinas de um curso de letras na Universidade Federal de Santa Catarina. Ele descreve a metodologia utilizada, que incluiu analisar as bibliografias dos programas de ensino e procurar as obras no sistema de bibliotecas. Os resultados mostraram que a maioria das obras estava disponível, principalmente na biblioteca central. O relatório conclui que a avaliação de coleções é essencial para manter os acervos atualizados e atender as necessidades dos usu
Este documento apresenta as diretrizes para a política de desenvolvimento da coleção da Biblioteca Escolar do Agrupamento de Escolas “Finisterra”. A biblioteca escolar tem como missão apoiar o processo educativo, promovendo a literacia, o acesso à informação e o desenvolvimento de competências para a aprendizagem ao longo da vida. As suas principais linhas de ação incluem o apoio ao currículo, a leitura, projetos com a comunidade e a gestão da coleção. A política estabelece critérios de seleção,
Este documento estabelece as políticas e critérios para o desenvolvimento da coleção da biblioteca escolar EB 2,3 Marinhais. A biblioteca visa fornecer recursos que atendam às necessidades da comunidade escolar e promovam a aprendizagem, cultura e lazer. As aquisições devem garantir diversidade de pontos de vista e formatos de acordo com as necessidades dos usuários.
Preparando sua biblioteca_para_avalia_ca_o_do_mecIasp
Este documento fornece orientações sobre como preparar a biblioteca de uma instituição de ensino superior para a avaliação do Ministério da Educação brasileiro (MEC). Ele discute a importância de ter um acervo atualizado e adequado, recursos humanos qualificados, e instalações apropriadas para atender às necessidades dos usuários e aos critérios de avaliação do MEC.
O documento descreve as principais classes e interfaces do pacote java.util que representam coleções como listas, conjuntos e mapas. São descritas as interfaces Collection, List, Set e Map e suas subclasses mais comuns como ArrayList, LinkedList, HashSet, HashMap e TreeMap.
Este manual descreve os procedimentos da biblioteca escolar, incluindo a seleção, aquisição, tratamento técnico, catalogação, classificação, cotação e arrumação dos documentos. Também aborda a organização de dossiês temáticos, a biblioteca itinerante e empréstimos.
O documento discute os processos de seleção e aquisição de materiais para bibliotecas, incluindo conceitos, critérios de seleção, tipos de aquisição e considerações sobre o desenvolvimento de coleções.
O documento fornece dicas para avaliar atividades de pesquisa na Internet realizadas por alunos. Sugere combinar claramente com os alunos o resultado esperado, como compreensão de páginas, respostas a questões ou produção de texto. Também recomenda divulgar amplamente os critérios de avaliação e discuti-los com os alunos.
Avaliação de coleções do acervo do curso de Graduação de Espanholdaianadelima
Este documento resume um relatório sobre a avaliação da coleção de livros de quatro disciplinas de um curso de letras na Universidade Federal de Santa Catarina. Ele descreve a metodologia utilizada, que incluiu analisar as bibliografias dos programas de ensino e procurar as obras no sistema de bibliotecas. Os resultados mostraram que a maioria das obras estava disponível, principalmente na biblioteca central. O relatório conclui que a avaliação de coleções é essencial para manter os acervos atualizados e atender as necessidades dos usu
As bibliotecas evoluíram de instituições privadas que guardavam conhecimento para poucos, para locais públicos de acesso ao saber. A automação e a internet transformaram as bibliotecas em ambientes digitais e interativos, onde os usuários compartilham informações e criam conteúdo (Biblioteca 2.0).
Relatório de avaliação da Biblioteca ESSPS - Domínio DLurdes Meneses
O relatório resume a avaliação da gestão da biblioteca escolar da Escola Secundária de S. Pedro do Sul no ano letivo de 2011/2012. As principais conclusões são: (1) A biblioteca está bem integrada nas atividades da escola e apoia o desenvolvimento curricular; (2) A direção da escola valoriza a biblioteca e fornece recursos adequados; (3) A biblioteca responde às necessidades da escola através de um horário flexível e apoiando os professores e alunos com suas necessidades de pesquisa e estudo.
Avaliação de coleções - Biblioteca Central do GragoatáIgor Falce
O documento descreve um estudo da coleção de livros do curso de Arquivologia da UFF. Avaliou-se a completude, atualidade, uso e estado físico da coleção, comparando-a com as bibliografias básicas das disciplinas. A coleção apresentou pontos positivos e negativos dependendo da disciplina, requerendo melhorias.
O documento discute o desenvolvimento de coleções em bibliotecas universitárias com base em uma abordagem quantitativa. Ele explora como a análise de citações em teses de doutorado pode ser usada para identificar as necessidades de usuários e direcionar a política de aquisição de materiais. Também examina como métodos bibliométricos como a análise de citações podem auxiliar na tomada de decisão sobre a seleção e gestão de coleções.
Este documento define as políticas e critérios para o desenvolvimento da coleção das bibliotecas escolares de um agrupamento, incluindo a seleção, aquisição, organização e preservação dos recursos. Estabelece os princípios de liberdade intelectual e igualdade de acesso, considerando as necessidades dos utilizadores e o currículo. Fornece critérios específicos para diferentes tipos de materiais como ficção, não ficção, obras de referência e recursos eletrónicos.
1) O documento descreve a avaliação da subclasse 7.0 da coleção da Biblioteca Escolar da Escola Secundária Artística António Arroio.
2) Foram utilizados métodos centrados na coleção e nos utilizadores para avaliar a idade média dos itens e adequação da coleção aos programas e necessidades dos professores.
3) Os resultados da avaliação irão fornecer informações sobre como a coleção pode ser melhorada para apoiar as atividades curriculares.
3 Desenvolvimento de coleções: comunidade usuáriaLeticia Strehl
O documento discute comunidades e necessidades informacionais. Apresenta que as necessidades da comunidade como um todo devem ser levadas em conta ao desenvolver coleções, não apenas dos usuários mais frequentes. Também discute o livro "A Cauda Longa" de Chris Anderson e como ele ensina sobre necessidades e hábitos informacionais.
O documento discute avaliação de coleções de bibliotecas, abordando aspectos fundamentais, métodos quantitativos e qualitativos. As abordagens incluem analisar tamanho, crescimento, gastos, estudos de uso e opiniões de especialistas. A avaliação identifica pontos fortes e fracos para melhorar a disponibilidade e acesso às coleções.
Este documento apresenta a política de desenvolvimento da coleção para as bibliotecas escolares do Agrupamento de Escolas de Sátão nos anos de 2013 a 2017. Detalha os princípios gerais, objetivos e funções das bibliotecas, caracteriza as comunidades de utilizadores e as bibliotecas fisicamente, e estabelece critérios para seleção, aquisição, desbaste e avaliação da coleção. A política visa assegurar a consistência dos procedimentos e fornecer recursos adequados para apoiar o processo educativo
O documento introduz o planejamento de coleções como atividade de gestão bibliotecária. Discute os elementos-chave de uma política de desenvolvimento de coleções, incluindo objetivos, análise da comunidade usuária, escopo da coleção, critérios de seleção e aquisição, e avaliação e desbastamento da coleção.
Trabalho apresentado à disciplina Formação do Acervo por alunos do 8º período do curso de Biblioteconomia da UFMG tendo por base o livro Desenvolvimento de Coleções do autor Waldomiro Vergueiro.
O documento discute conceitos básicos sobre coleções no Java. Ele apresenta os objetivos da discussão que são: distinguir cada tipo de coleção, escolher a melhor implementação de coleção para cada uso, conhecer as principais interfaces e implementações de coleção, e entender os conceitos fundamentais de igualdade no Java necessários para trabalhar com coleções.
O documento descreve classes Java e pacotes padrão, como pacotes de entrada e saída de dados, banco de dados e interface gráfica. Ele apresenta as classes Java.lang e pacotes como java.io, java.sql e java.swing.
O documento resume uma aula sobre Java Collections Framework, JDBC e operações básicas em banco de dados. Aborda interfaces como List, Set, Map e suas implementações mais comuns. Também explica conectividade com bancos de dados relacionais usando JDBC e exemplos de consultas, inserções, atualizações e exclusões.
O documento resume uma aula sobre Java Collections Framework, JDBC e operações em banco de dados. Aborda conceitos como coleções, generics, interfaces como List, Set, Map, além de conectividade com bancos de dados relacionais e exemplos de consultas, inserções, atualizações e deleções.
Collections fornece classes para estruturas de dados como listas, conjuntos e mapas. Listas mantêm uma ordem e permitem elementos duplicados. Conjuntos não permitem duplicados e não garantem ordem. Mapas mapeiam chaves para valores.
Este documento discute pacotes e encapsulamento na API Java 2. Aborda os principais pacotes da API Java como java.lang, java.util, java.io e java.net. Explora classes fundamentais como Object e classes utilitárias como Date e Math. Também explica como criar pacotes personalizados e arquivos JAR e métodos importantes como equals(), hashCode() e clone().
Este documento discute pacotes e encapsulamento em Java, abordando os principais pacotes da API Java como java.lang e java.util, além de explicar como criar pacotes e classes em Java, implementando métodos como equals() e clone().
Este documento discute pacotes e encapsulamento em Java, abordando os principais pacotes da API Java como java.lang e java.util, além de explicar como criar pacotes e classes em Java, implementando métodos como equals() e clone().
O documento discute classes abstratas, anônimas e interfaces em Java. Apresenta classes abstratas como aquelas que não podem ser instanciadas e servem apenas como modelo para classes concretas. Discute também métodos abstratos que forçam classes filhas a implementá-los. Apresenta interfaces como contratos que definem métodos públicos e abstratos que classes podem implementar. E explica classes anônimas como classes sem nome usadas para implementar interfaces.
O documento discute estruturas de repetição e arrays em Java. Apresenta loops while e for, e demonstra como usá-los para resolver problemas iterativos. Também explica arrays, como declará-los, acessar elementos e percorrê-los. Por fim, fornece exercícios sobre esses tópicos para o leitor praticar.
As bibliotecas evoluíram de instituições privadas que guardavam conhecimento para poucos, para locais públicos de acesso ao saber. A automação e a internet transformaram as bibliotecas em ambientes digitais e interativos, onde os usuários compartilham informações e criam conteúdo (Biblioteca 2.0).
Relatório de avaliação da Biblioteca ESSPS - Domínio DLurdes Meneses
O relatório resume a avaliação da gestão da biblioteca escolar da Escola Secundária de S. Pedro do Sul no ano letivo de 2011/2012. As principais conclusões são: (1) A biblioteca está bem integrada nas atividades da escola e apoia o desenvolvimento curricular; (2) A direção da escola valoriza a biblioteca e fornece recursos adequados; (3) A biblioteca responde às necessidades da escola através de um horário flexível e apoiando os professores e alunos com suas necessidades de pesquisa e estudo.
Avaliação de coleções - Biblioteca Central do GragoatáIgor Falce
O documento descreve um estudo da coleção de livros do curso de Arquivologia da UFF. Avaliou-se a completude, atualidade, uso e estado físico da coleção, comparando-a com as bibliografias básicas das disciplinas. A coleção apresentou pontos positivos e negativos dependendo da disciplina, requerendo melhorias.
O documento discute o desenvolvimento de coleções em bibliotecas universitárias com base em uma abordagem quantitativa. Ele explora como a análise de citações em teses de doutorado pode ser usada para identificar as necessidades de usuários e direcionar a política de aquisição de materiais. Também examina como métodos bibliométricos como a análise de citações podem auxiliar na tomada de decisão sobre a seleção e gestão de coleções.
Este documento define as políticas e critérios para o desenvolvimento da coleção das bibliotecas escolares de um agrupamento, incluindo a seleção, aquisição, organização e preservação dos recursos. Estabelece os princípios de liberdade intelectual e igualdade de acesso, considerando as necessidades dos utilizadores e o currículo. Fornece critérios específicos para diferentes tipos de materiais como ficção, não ficção, obras de referência e recursos eletrónicos.
1) O documento descreve a avaliação da subclasse 7.0 da coleção da Biblioteca Escolar da Escola Secundária Artística António Arroio.
2) Foram utilizados métodos centrados na coleção e nos utilizadores para avaliar a idade média dos itens e adequação da coleção aos programas e necessidades dos professores.
3) Os resultados da avaliação irão fornecer informações sobre como a coleção pode ser melhorada para apoiar as atividades curriculares.
3 Desenvolvimento de coleções: comunidade usuáriaLeticia Strehl
O documento discute comunidades e necessidades informacionais. Apresenta que as necessidades da comunidade como um todo devem ser levadas em conta ao desenvolver coleções, não apenas dos usuários mais frequentes. Também discute o livro "A Cauda Longa" de Chris Anderson e como ele ensina sobre necessidades e hábitos informacionais.
O documento discute avaliação de coleções de bibliotecas, abordando aspectos fundamentais, métodos quantitativos e qualitativos. As abordagens incluem analisar tamanho, crescimento, gastos, estudos de uso e opiniões de especialistas. A avaliação identifica pontos fortes e fracos para melhorar a disponibilidade e acesso às coleções.
Este documento apresenta a política de desenvolvimento da coleção para as bibliotecas escolares do Agrupamento de Escolas de Sátão nos anos de 2013 a 2017. Detalha os princípios gerais, objetivos e funções das bibliotecas, caracteriza as comunidades de utilizadores e as bibliotecas fisicamente, e estabelece critérios para seleção, aquisição, desbaste e avaliação da coleção. A política visa assegurar a consistência dos procedimentos e fornecer recursos adequados para apoiar o processo educativo
O documento introduz o planejamento de coleções como atividade de gestão bibliotecária. Discute os elementos-chave de uma política de desenvolvimento de coleções, incluindo objetivos, análise da comunidade usuária, escopo da coleção, critérios de seleção e aquisição, e avaliação e desbastamento da coleção.
Trabalho apresentado à disciplina Formação do Acervo por alunos do 8º período do curso de Biblioteconomia da UFMG tendo por base o livro Desenvolvimento de Coleções do autor Waldomiro Vergueiro.
O documento discute conceitos básicos sobre coleções no Java. Ele apresenta os objetivos da discussão que são: distinguir cada tipo de coleção, escolher a melhor implementação de coleção para cada uso, conhecer as principais interfaces e implementações de coleção, e entender os conceitos fundamentais de igualdade no Java necessários para trabalhar com coleções.
O documento descreve classes Java e pacotes padrão, como pacotes de entrada e saída de dados, banco de dados e interface gráfica. Ele apresenta as classes Java.lang e pacotes como java.io, java.sql e java.swing.
O documento resume uma aula sobre Java Collections Framework, JDBC e operações básicas em banco de dados. Aborda interfaces como List, Set, Map e suas implementações mais comuns. Também explica conectividade com bancos de dados relacionais usando JDBC e exemplos de consultas, inserções, atualizações e exclusões.
O documento resume uma aula sobre Java Collections Framework, JDBC e operações em banco de dados. Aborda conceitos como coleções, generics, interfaces como List, Set, Map, além de conectividade com bancos de dados relacionais e exemplos de consultas, inserções, atualizações e deleções.
Collections fornece classes para estruturas de dados como listas, conjuntos e mapas. Listas mantêm uma ordem e permitem elementos duplicados. Conjuntos não permitem duplicados e não garantem ordem. Mapas mapeiam chaves para valores.
Este documento discute pacotes e encapsulamento na API Java 2. Aborda os principais pacotes da API Java como java.lang, java.util, java.io e java.net. Explora classes fundamentais como Object e classes utilitárias como Date e Math. Também explica como criar pacotes personalizados e arquivos JAR e métodos importantes como equals(), hashCode() e clone().
Este documento discute pacotes e encapsulamento em Java, abordando os principais pacotes da API Java como java.lang e java.util, além de explicar como criar pacotes e classes em Java, implementando métodos como equals() e clone().
Este documento discute pacotes e encapsulamento em Java, abordando os principais pacotes da API Java como java.lang e java.util, além de explicar como criar pacotes e classes em Java, implementando métodos como equals() e clone().
O documento discute classes abstratas, anônimas e interfaces em Java. Apresenta classes abstratas como aquelas que não podem ser instanciadas e servem apenas como modelo para classes concretas. Discute também métodos abstratos que forçam classes filhas a implementá-los. Apresenta interfaces como contratos que definem métodos públicos e abstratos que classes podem implementar. E explica classes anônimas como classes sem nome usadas para implementar interfaces.
O documento discute estruturas de repetição e arrays em Java. Apresenta loops while e for, e demonstra como usá-los para resolver problemas iterativos. Também explica arrays, como declará-los, acessar elementos e percorrê-los. Por fim, fornece exercícios sobre esses tópicos para o leitor praticar.
O documento discute a linguagem de programação C# (C sharp). C# é uma linguagem orientada a objetos e derivada de C++ e C, fazendo parte do framework .NET da Microsoft. O documento também fornece exemplos básicos de conceitos como classes, métodos, variáveis, loops e tipos de acesso em C#.
O documento discute conceitos importantes de opicionais em Swift, como:
1) Opcionais podem representar a ausência de valor e são úteis para representar valores que podem ou não existir;
2) Existem diferentes formas de lidar com valores opcionais, como desempacotamento forçado, vinculação opcional e operador nil coalescing;
3) Valores opcionais podem ser encadeados para acessar propriedades e métodos de forma segura.
O documento descreve o domínio de escolas de magia e apresenta as principais entidades e relacionamentos entre elas, como escolas, casas, alunos, professores, disciplinas e torneios. O texto fornece detalhes sobre os atributos e relações entre classes como escolas que possuem casas, alunos matriculados em casas, alunos que frequentam disciplinas ministradas por professores e escolas que participam de torneios.
Curso de Delphi - Lógica de ProgramacaoJosé Araújo
O documento apresenta os principais conceitos de lógica de programação, incluindo lógica, algoritmos, variáveis, estruturas de decisão e repetição. Explica como a lógica é usada no dia a dia e como ela é essencial para desenvolvimento de sistemas. Também introduz a linguagem Portugol para escrever algoritmos de forma estruturada.
1) O documento apresenta diretrizes de nomenclatura e padrões de código para classes, métodos, variáveis e constantes em Java.
2) São descritos padrões como usar camelCase para nomes de classes, métodos e variáveis, e letras maiúsculas separadas por underline para constantes.
3) São explicados prefixos para métodos getters e setters, como get e set, respectivamente.
1) O documento discute estruturas de dados como Map e Set, métodos importantes como put(), get(), e implementações como HashMap e HashSet.
2) Map armazena dados em pares chave-valor e não permite chaves duplicadas, enquanto Set armazena elementos únicos sem ordenação.
3) Threads permitem executar tarefas simultaneamente através de métodos como start(), run(), sleep(), enquanto synchronized garante acesso exclusivo a recursos compartilhados.
O documento discute as vantagens e desvantagens de diferentes linguagens de programação e abordagens. Ele enfatiza que nenhuma linguagem é perfeita e que as escolhas devem ser baseadas no contexto e objetivos de cada projeto. Além disso, destaca a importância de os desenvolvedores reconhecerem tanto os pontos fortes quanto as limitações de suas ferramentas.
Java utiliza uma máquina virtual que traduz as aplicações para as chamadas do sistema operacional, permitindo que as aplicações rodem independentemente do sistema operacional. A máquina virtual Java (JVM) executa as aplicações Java e permite o desenvolvimento usando ferramentas como o compilador Javac e o kit de desenvolvimento JDK. O documento descreve também conceitos básicos de programação em Java como tipos primitivos, classes, métodos, fluxos de controle e orientação a objetos.
O documento resume conceitos fundamentais de C#, incluindo: 1) tipos de valor e referência, pilha e heap; 2) boxing e unboxing; 3) coleções genéricas como List, Dictionary e suas complexidades; 4) IDisposable e uso de recursos; 5) diferença entre throw e throw ex.
Atividade letra da música - Espalhe Amor, Anavitória.Mary Alvarenga
A música 'Espalhe Amor', interpretada pela cantora Anavitória é uma celebração do amor e de sua capacidade de transformar e conectar as pessoas. A letra sugere uma reflexão sobre como o amor, quando verdadeiramente compartilhado, pode ultrapassar barreiras alcançando outros corações e provocando mudanças positivas.
Slides Lição 10, Central Gospel, A Batalha Do Armagedom, 1Tr24.pptxLuizHenriquedeAlmeid6
Slideshare Lição 10, Central Gospel, A Batalha Do Armagedom, 1Tr24, Pr Henrique, EBD NA TV, Revista ano 11, nº 1, Revista Estudo Bíblico Jovens E Adultos, Central Gospel, 2º Trimestre de 2024, Professor, Tema, Os Grandes Temas Do Fim, Comentarista, Pr. Joá Caitano, estudantes, professores, Ervália, MG, Imperatriz, MA, Cajamar, SP, estudos bíblicos, gospel, DEUS, ESPÍRITO SANTO, JESUS CRISTO, Com. Extra Pr. Luiz Henrique, 99-99152-0454, Canal YouTube, Henriquelhas, @PrHenrique
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptxLuizHenriquedeAlmeid6
Slideshare Lição 11, Central Gospel, Os Mortos Em Cristo, 1Tr24, Pr Henrique, EBD NA TV, Revista ano 11, nº 1, Revista Estudo Bíblico Jovens E Adultos, Central Gospel, 2º Trimestre de 2024, Professor, Tema, Os Grandes Temas Do Fim, Comentarista, Pr. Joá Caitano, estudantes, professores, Ervália, MG, Imperatriz, MA, Cajamar, SP, estudos bíblicos, gospel, DEUS, ESPÍRITO SANTO, JESUS CRISTO, Com. Extra Pr. Luiz Henrique, 99-99152-0454, Canal YouTube, Henriquelhas, @PrHenrique
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
Collections E Generics
1. ® TM
Certificação Sun para Programador Java 6
Collections
Tomaz Lavieri
Sun Certified Java Programmer 6
tomazlavieri@gmail.com
http://java-i9se.blogspot.com.br
2. Collections
Objetivos:
• Ao final desta apresentação espera-se que você
saiba:
– Distinguir cada tipo de Coleção.
– Escolher a melhor implementação de Coleção para
cada tipo de uso.
– Saber a diferença entre as Interfaces: Collection, Set,
Queue, List, SortedSet, NavigableSet, Map,
SortedMap e NavigableMap.
– Conhecer as implementações básicas: ArrayList,
Vector, LinkedList, PriorityQueue, TreeSet, HashSet,
LinkedHashSet, TreeMap, HashMap e
LinkedHashMap.
3. Collections
Objetivos:
• Ao final desta apresentação espera-se que você
saiba:
– Distinguir cada tipo de Coleção.
– Escolher a melhor implementação de Coleção para
cada tipo de uso.
– Saber a diferença entre as Interfaces: Collection, Set,
Queue, List, SortedSet, NavigableSet, Map,
SortedMap e NavigableMap.
– Conhecer as implementações básicas: ArrayList,
Vector, LinkedList, PriorityQueue, TreeSet, HashSet,
LinkedHashSet, TreeMap, HashMap e
LinkedHashMap.
4. Collections
Objetivos:
• Ao final desta apresentação espera-se que você
saiba:
– Distinguir cada tipo de Coleção.
– Escolher a melhor implementação de Coleção (entre
as básicas) para cada tipo de uso.
– Saber a diferença entre as Interfaces: Collection, Set,
Queue, List, SortedSet, NavigableSet, Map,
SortedMap e NavigableMap.
– Conhecer as implementações básicas: ArrayList,
Vector, LinkedList, PriorityQueue, TreeSet, HashSet,
LinkedHashSet, TreeMap, HashMap e
LinkedHashMap.
5. Collections
Objetivos:
• Ao final desta apresentação espera-se que você
saiba:
– Distinguir cada tipo de Coleção.
– Escolher a melhor implementação de Coleção (entre
as básicas) para cada tipo de uso.
– Saber a diferença entre as Interfaces: Collection, Set,
Queue, List, SortedSet, NavigableSet, Map,
SortedMap e NavigableMap.
– Conhecer as implementações básicas: ArrayList,
Vector, LinkedList, PriorityQueue, TreeSet, HashSet,
LinkedHashSet, TreeMap, HashMap e
LinkedHashMap.
6. Collections
Objetivos:
• Ao final desta apresentação espera-se que você
saiba:
– Distinguir cada tipo de Coleção.
– Escolher a melhor implementação de Coleção (entre
as básicas) para cada tipo de uso.
– Saber a diferença entre as Interfaces: Collection, Set,
Queue, List, SortedSet, NavigableSet, Map,
SortedMap e NavigableMap.
– Conhecer as implementações básicas: ArrayList,
Vector, LinkedList, PriorityQueue, TreeSet, HashSet,
LinkedHashSet, TreeMap, HashMap e
LinkedHashMap.
9. Collections
• Pre-requisitos:
– Igualdade: Para se trabalhar com coleções é
preciso entender a igualdade em Java
• Porque é preciso?
10. Collections
• Pre-requisitos:
– Igualdade: Para se trabalhar com coleções é
preciso entender a igualdade em Java
• Porque é preciso?
– Quando chegarmos lá tudo ficará mais claro,
mas adiantando, varias funcionalidades de
coleções como contains(Object o) – que
verifica se existe um objeto na coleção –
precisa testar a igualdade para funcionar.
12. Collections
• Como funciona igualdade em Java ?
pessoa1 == pessoa2
• Isso irá testar apenas se as duas variáveis
referenciam uma única instancia!
13. Collections
• Como então saber, por exemplo, quando
dois objetos Pessoa são significantemente
iguais?
14. Collections
• Como então saber, por exemplo, quando
dois objetos Pessoa são significantemente
iguais?
– Para esse tipo de teste você deve usar um
método que todo objeto Java tem
equals(Object o)
15. Collections
• Como então saber, por exemplo, quando
dois objetos Pessoa são significantemente
iguais?
– Para esse tipo de teste você deve usar um
método que todo objeto Java tem
equals(Object o)
• Então nosso teste de igualdade seria:
pessoa1.equals(pessoa2)
18. Collections
• Só isso resolve?
– Não
• Por padrão o método equals de Object faz
o mesmo que o operador ==
19. Collections
• Só isso resolve?
– Não
• Por padrão o método equals de Object faz
o mesmo que o operador ==
public class Object {
//..
public boolean equals(Object obj) {
return (this == obj);
}
//…
20. Collections
• Então se queremos definir em nosso
modelo que dois objetos Pessoa são
iguais quando, por exemplo, seus cpf são
iguais?
21. Collections
• Então se queremos definir em nosso
modelo que dois objetos Pessoa são
iguais quando, por exemplo, seus cpf são
iguais?
– Neste caso nós precisamos ensinar ao nosso
programa a igualdade entre nossos objetos
22. Collections
• Então se queremos definir em nosso
modelo que dois objetos Pessoa são
iguais quando, por exemplo, seus cpf são
iguais?
– Neste caso nós precisamos ensinar ao nosso
programa a igualdade entre nossos objetos
• Como fazer isso??
23. Collections
• Então se queremos definir em nosso
modelo que dois objetos Pessoa são
iguais quando, por exemplo, seus cpf são
iguais?
– Neste caso nós precisamos ensinar ao nosso
programa a igualdade entre nossos objetos
• Como fazer isso??
– Sobrescrevendo o equals
25. Collections
• Mas não basta simplesmente
sobrescrever!
• E existe um contrato de equals que
deve ser rigorosamente seguido para o
bom funcionamento do programa e da
Java Collections Framework
26. Collections
• O contrato diz que equals é:
– Reflexível: a.equals(a) == true
– Simétrico: a.equals(b) == b.equals(a)
– Transitivo: se a.equals(b) && b.equals(c) == true .:.
a.equals(c) também é true.
– Consistente: a.equals(b) deve retornar sempre true
ou sempre falso, desde que nenhuma propriedade do
do Objeto que faz parte do teste equals seja alterada.
– Deve retornar false quando testado contra
uma variável null
27. Collections
• O contrato diz que equals é:
– Reflexível: a.equals(a) == true
– Simétrico: a.equals(b) == b.equals(a)
– Transitivo: se a.equals(b) && b.equals(c) == true .:.
a.equals(c) também é true.
– Consistente: a.equals(b) deve retornar sempre true
ou sempre falso, desde que nenhuma propriedade do
do Objeto que faz parte do teste equals seja alterada.
– Deve retornar false quando testado contra
uma variável null
28. Collections
• O contrato diz que equals é:
– Reflexível: a.equals(a) == true
– Simétrico: a.equals(b) == b.equals(a)
– Transitivo: se a.equals(b) && b.equals(c) == true .:.
a.equals(c) também é true.
– Consistente: a.equals(b) deve retornar sempre true
ou sempre falso, desde que nenhuma propriedade do
do Objeto que faz parte do teste equals seja alterada.
– Deve retornar false quando testado contra
uma variável null
29. Collections
• O contrato diz que equals é:
– Reflexível: a.equals(a) == true
– Simétrico: a.equals(b) == b.equals(a)
– Transitivo: se a.equals(b) && b.equals(c) == true .:.
a.equals(c) == true.
– Consistente: a.equals(b) deve retornar sempre true
ou sempre falso, desde que nenhuma propriedade do
do Objeto que faz parte do teste equals seja alterada.
– Deve retornar false quando testado contra
uma variável null
30. Collections
• O contrato diz que equals é:
– Reflexível: a.equals(a) == true
– Simétrico: a.equals(b) == b.equals(a)
– Transitivo: se a.equals(b) && b.equals(c) == true .:.
a.equals(c) == true
– Consistente: a.equals(b) deve retornar sempre true
ou sempre falso, desde que nenhuma propriedade do
do Objeto que faz parte do teste equals seja alterada.
– Deve retornar false quando testado contra
uma variável null
31. Collections
• Portanto para nossa classe Pessoa podemos
definir um equals assim:
public class Pessoa {
private String cpf;
//...
@Override
public boolean equals(Object p) {
if (cpf == null)
return false;
return (p instanceof Pessoa) &&
this.cpf.equals(((Pessoa)p).cpf);
}
//...
}
32. Collections
• Portanto para nossa classe Pessoa podemos
definir um equals assim:
public class Pessoa {
private String cpf;
//...
@Override // não é necessário mas é bom
public boolean equals(Object p) {
if (cpf == null)
return false;
return (p instanceof Pessoa) &&
this.cpf.equals(((Pessoa)p).cpf);
}
//...
}
33. Collections
• Portanto para nossa classe Pessoa podemos
definir um equals assim: Eu não podia colocar
public class Pessoa { A classe Pessoa?
private String cpf; No lugar de Objeto ?
//...
@Override
public boolean equals(Object p) {
Pessoa
if (cpf == null)
return false;
return (p instanceof Pessoa) &&
this.cpf.equals(((Pessoa)p).cpf);
}
//...
}
34. Collections
• Portanto para nossa classe Pessoa podemos
definir um equals assim: Eu não podia colocar
public class Pessoa { A classe Pessoa?
private String cpf; No lugar de Objeto ?
//...
@Override
public boolean equals(Object p) {
Pessoa
if (cpf == null) NÃO!!!!
return false; Pois é preciso
return (p instanceof Pessoa) && sobrescrever o
this.cpf.equals(((Pessoa)p).cpf); método da classe
} Object e portanto
//... manter a mesma
} assinatura
35. Collections
• Então é isso basta sobrescrever o método
equals corretamente na minha classe e já
posso usar:
pessoa1.equals(pessoa2)
• Não preciso fazer mais nada?
36. Collections
• Então é isso basta sobrescrever o método
equals corretamente na minha classe e já
posso usar:
pessoa1.equals(pessoa2)
• Não preciso fazer mais nada?
– ERRADO! Precisa sim! E é ai o erro mais comum de
quem trabalha com collections
37. Collections
• Então é isso basta sobrescrever o método
equals corretamente na minha classe e já
posso usar:
pessoa1.equals(pessoa2)
• Não preciso fazer mais nada?
– ERRADO! Precisa sim! E é ai o erro mais comum de
quem trabalha com collections
• O contrato de equals(Object o) esta
fortemente ligado ao de hashCode()
39. Collections
• E pra que serve esse hashCode() ?
– Calma que assim que chegar em coleções falaremos
dele ao estudar HashSet, LinkedHashSet, HashMap,
LinkedHashMap e Hashtable
40. Collections
• E pra que serve esse hashCode() ?
– Calma que assim que chegar em coleções falaremos
dele ao estudar HashSet, LinkedHashSet, HashMap,
LinkedHashMap e Hashtable
• Certo mas então o que ele tem a ver com meu
teste de igualdade ??
41. Collections
• E pra que serve esse hashCode() ?
– Calma que assim que chegar em coleções falaremos
dele ao estudar HashSet, LinkedHashSet, HashMap,
LinkedHashMap e Hashtable
• Certo mas então o que ele tem a ver com meu
teste de igualdade ??
– As definições do contrato de hashCode() o ligam
diretamente ao teste de igualdade, portanto sempre
que sobrescrever equals(Object o) você terá que
sobrescrever também o hashCode()
42. Collections
• O contrato do hashCode() diz:
– É constante: qualquer chamada a hashCode() deve sempre
retornar o mesmo interiro, desde que as propriedade usadas no
teste equals(Object o) não sejam alteradas.
– É igual para objetos iguais: a.equals(b) == true .:.
a.hashCode() == b.hashCode()
– Não é necessário ser diferente para objetos
diferentes: ou seja, se a.equals(b) == false .:. a.hashCode()
== b.hashCode() || hashCode() != b.hashCode()
43. Collections
• O contrato do hashCode() diz:
– É constante: qualquer chamada a hashCode() deve sempre
retornar o mesmo inteiro, desde que as propriedade usadas no
teste equals(Object o) não sejam alteradas.
– É igual para objetos iguais: a.equals(b) == true .:.
a.hashCode() == b.hashCode()
– Não é necessário ser diferente para objetos
diferentes: ou seja, se a.equals(b) == false .:. a.hashCode()
== b.hashCode() || hashCode() != b.hashCode()
44. Collections
• O contrato do hashCode() diz:
– É constante: qualquer chamada a hashCode() deve sempre
retornar o mesmo inteiro, desde que as propriedade usadas no
teste equals(Object o) não sejam alteradas.
– É igual para objetos iguais: a.equals(b) == true .:.
a.hashCode() == b.hashCode()
– Não é necessário ser diferente para objetos
diferentes: ou seja, se a.equals(b) == false .:. a.hashCode()
== b.hashCode() || hashCode() != b.hashCode()
45. Collections
• O contrato do hashCode() diz:
– É constante: qualquer chamada a hashCode() deve sempre
retornar o mesmo inteiro, desde que as propriedade usadas no
teste equals(Object o) não sejam alteradas.
– É igual para objetos iguais: a.equals(b) == true .:.
a.hashCode() == b.hashCode()
– Não é necessário ser diferente para objetos
diferentes: ou seja, se a.equals(b) == false .:.
a.hashCode() == b.hashCode() || hashCode() != b.hashCode()
46. Collections
• Por padrão o método hashCode() é
diferente para cada instancia de Object.
• Não é implementado em java e sim com
linguagem nativa:
public class Object {
//..
public native int hashCode();
//…
}
47. Collections
• Por padrão o método hashCode() é
diferente para cada instancia de Object.
• Não é implementado em java e sim com
linguagem nativa:
public class Object {
//..
public native int hashCode();
//…
}
48. Collections
• Portanto no nosso modelo dois objetos
Pessoa com o mesmo cpf, vai retornar
hashCode diferentes (pois esse é o
padrão do hashCode)
• Isto fere o contrato de hashCode, pois:
pessoa1.equals(pessoa2) == true
pessoa1.hashCode() != pessoa2.hashCode()
49. Collections
• Portanto no nosso modelo dois objetos
Pessoa com o mesmo cpf, vai retornar
hashCode diferentes (pois esse é o
padrão do hashCode)
• Isto fere o contrato de hashCode, pois:
pessoa1.equals(pessoa2) == true
pessoa1.hashCode() != pessoa2.hashCode()
50. Collections
Pessoa p1 = new Pessoa("123.456.789-00"); //igual a p2
String text = "São iguais? %b ... hashCodes? %d , %d n";
for (int i = 0; i < 30; i++) {
Pessoa p2 = new Pessoa("123.456.789-00"); //igual a p1
System.out.printf( text, p1.equals(p2), p1.hashCode(),
p2.hashCode() );
}
• O output disso é algo como:
– São iguais? true ... hashCodes? 11394033 , 4384790
– São iguais? true ... hashCodes? 11394033 , 24355087
– São iguais? true ... hashCodes? 11394033 , 5442986
– São iguais? true ... hashCodes? 11394033 , 10891203
– São iguais? true ... hashCodes? 11394033 , 9023134
– ....... etc
51. Collections
• Portanto para nossa classe Pessoa um
hashCode() valido pode ser:
public class Pessoa {
private String cpf;
//...
@Override
public int hashCode() {
return (cpf == null) ? 0 : cpf.hashCode();
}
//...
}
52. Collections
• Portanto para nossa classe Pessoa um
hashCode() valido pode ser:
public class Pessoa {
private String cpf;
//...
@Override // não é necessário mas é bom
public int hashCode() {
return (cpf == null) ? 0 : cpf.hashCode();
}
//...
}
53. Collections
• Portanto para nossa classe Pessoa um
hashCode() valido pode ser:
public class Pessoa { Eu não poderia retornar
private String cpf; sempre o mesmo número?
Isso não feriria o contrato!
//...
@Override
public int hashCode() {
return (cpf == null) ? 0 : cpf.hashCode();
12;
}
//...
}
54. Collections
• Portanto para nossa classe Pessoa um
hashCode() valido pode ser:
public class Pessoa { Eu não poderia retornar
private String cpf; sempre o mesmo número?
Isso não feriria o contrato!
//...
@Override
public int hashCode() {
SIM! Poderia...
return (cpf == null) ? 0 : cpf.hashCode();nem um
12; Porem não é
pouco eficiente, como
} veremos mais adiante
//... quando estudarmos as
coleções que usam hash
}
56. Collections
• Java Collections Framework (JCF)
– Existem duas interfaces principais são elas:
• java.util.Collection: uma coleção de objetos
• java.util.Map: uma coleção de chave objeto
– Toda a estrutura da JCF é baseada e
descendem da estrutura destas duas
interfaces
57. Collections
• Java Collections Framework (JCF)
– Existem duas interfaces principais são elas:
• java.util.Collection: uma coleção de objetos
• java.util.Map: uma coleção de chave objeto
– Toda a estrutura da JCF é baseada e
descendem da estrutura destas duas
interfaces
• Então como seria esta estrutura ??
61. Collections
• E eu preciso saber de tudo isso ????
– SIM!!!! Para a certificação e para a vida de
programador java!
62. Collections
• E eu preciso saber de tudo isso ????
– SIM!!!! Para a certificação e para a vida de
programador java!
• Mas... devagar com andor que o santo é
de barro...
• Quais são as interfaces mesmo ??
65. Collections
• Métodos de java.util.Collection<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean contains(Object o)
boolean containsAll(Collection<?> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c)
boolean retainAll(Collection<?> c)
void clear()
int size()
boolean isEmpty()
Object[] toArray()
<T> T[] toArray(T[] a)
66. Collections
• Métodos de java.util.Collection<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean contains(Object o)
boolean containsAll(Collection<?> c) PERAI PERAI!!
boolean remove(Object o) O que é esse <E> ?
boolean removeAll(Collection<?> c) e esse add(E e) ?
e esse <? extends E> ?
boolean retainAll(Collection<?> c)
e esse <?>
void clear()
e aquele <T> T[] ???
int size()
boolean isEmpty()
Que classes são essas ?
Object[] toArray() T e E ???
<T> T[] toArray(T[] a)
67. Collections
• Métodos de java.util.Collection<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean contains(Object o)
boolean containsAll(Collection<?> c) PERAI PERAI!!
boolean remove(Object o) O que é esse <E> ?
boolean removeAll(Collection<?> c) e esse add(E e) ?
e esse <? extends E> ?
boolean retainAll(Collection<?> c)
e esse <?>
void clear() Isso se chama genéricos! e aquele <T> T[] ???
int size() Eu vou dar uma breve
boolean isEmpty() explicação apenas
introdutória, e voltamos Que classes são essas ?
Object[] toArray() para as Collections T e E ???
<T> T[] toArray(T[] a)
68. Collections
• O que são genéricos ?
– Os genéricos são amarrações que só existem em
tempo de compilação
– Existem classes genéricas e métodos genéricos
• Para Collection vamos focar em classes
genéricas, por exemplo:
public class ArrayList<E> ... {
boolean add(E e) {
...
}
}
69. Collections
• O que são genéricos ?
– Os genéricos são amarrações que só existem em
tempo de compilação
– Existem classes genéricas e métodos genéricos
• Para Collection vamos focar em classes
genéricas, por exemplo:
public class ArrayList<E> ... {
boolean add(E e) {
...
}
}
70. Collections
• O que são genéricos ?
– Os genéricos são amarrações que só existem em
tempo de compilação
– Existem classes genéricas e métodos genéricos
• Para Collection vamos focar em classes
genéricas... por exemplo:
public class ArrayList<E> ... {
boolean add(E e) {
...
}
}
71. Collections
• O que são genéricos ?
– Os genéricos são amarrações que só existem em
tempo de compilação
– Existem classes genéricas e métodos genéricos
• Para Collection vamos focar em classes
genéricas... por exemplo:
public class ArrayList<E> ... {
boolean add(E e) {
...
}
}
72. Collections
• O que acontece quando declaramos assim?
ArrayList<String> strings = new ArrayList<String>();
• Para o compilador, e apenas para o compilador
Todos os “T” viram “String”
boolean add(String e);
• Porem para o bytecode o “T” é sempre Object,
ou seja, depois que ta rodando o programa isso
some e tudo vira Object novamente
boolean add(Object e);
73. Collections
• O que acontece quando declaramos assim?
ArrayList<String> strings = new ArrayList<String>();
• Para o compilador, e apenas para o compilador
Todos os “T” viram “String”
boolean add(String e);
• Porem para o bytecode o “T” é sempre Object,
ou seja, depois que ta rodando o programa isso
some e tudo vira Object novamente
boolean add(Object e);
74. Collections
• O que acontece quando declaramos assim?
ArrayList<String> strings = new ArrayList<String>();
• Para o compilador, e apenas para o compilador
Todos os “T” viram “String”
boolean add(String e);
• Porem para o bytecode o “T” é sempre Object,
ou seja, depois que ta rodando o programa isso
some e tudo vira Object novamente
boolean add(Object e);
76. Collections
• E podemos criar a classe assim ??
ArrayList c = new ArrayList();
SIM!!! podemos!!! E o método gerado fica assim
boolean add(Object e);
77. Collections
• E podemos criar a classe assim ??
ArrayList c = new ArrayList();
SIM!!! podemos!!! E o método gerado fica assim
boolean add(Object e);
• E na realidade a classe continua sendo
desta forma, os tipos são apenas uma
amarração para forçar a codar
corretamente uma classe genérica.
78. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
79. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
• strings.add(a) só aceita Strings como
argumento.
• c.add(a) aceita qualquer Object
• Por exemplo .... =>
80. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
c.add(new Object());
strings.add(new Object());
strings.add(“abc”);
81. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
c.add(new Object()); // ok vai compilar
strings.add(new Object());
strings.add(“abc”);
82. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
c.add(new Object());
strings.add(new Object()); // não compila
strings.add(“abc”);
83. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
c.add(new Object());
strings.add(new Object());
strings.add(“abc”); // ok vai compilar
84. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
c.add(new Object()); // ok vai compilar
strings.add(new Object()); // não compila
strings.add(“abc”); // ok vai compilar
85. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
• Mas se você passar strings para c, você
terá um problemão
86. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
• Mas se você passar strings para c, você
terá um problemão
c = strings;
c.add(new Object()); // compila NÃO gera Exception
87. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
• Mas se você passar strings para c, você
terá um problemão
c = strings; // ok compila MAS É PERIGOSO!
c.add(new Object()); // compila NÃO gera Exception
88. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
• Mas se você passar strings para c, você
terá um problemão
c = strings; // ok compila MAS É PERIGOSO!
c.add(new Object()); // compila NÃO gera Exception
89. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
• Mas se você passar strings para c, você
terá um problemão
c = strings; // ok compila MAS É PERIGOSO!
c.add(new Object()); // compila NÃO gera Exception
90. Collections
• O problema esta quando você mistura
genérico e não genérico:
ArrayList<String> strings = new ArrayList<String>();
ArrayList c = new ArrayList();
• Mas se você passar strings para c, você
terá um problemão
c = strings; // ok compila MAS É PERIGOSO!
c.add(new Object()); // compila NÃO gera Exception
91. Collections
• O problema esta quando você mistura
genérico e não genérico:
Neste momento a collection strings
ArrayList<String> strings = new ArrayList<String>(); mesmo
passou a conter um Object
ArrayList c = new ArrayList(); sua tipagem impedindo isso,
a
isso pode ocorrer quando generico
• Mas se você passar tString para t, você
é misturado com não genericos
terá um problemão
c = strings; // ok compila MAS É PERIGOSO!
c.add(new Object()); // compila NÃO gera Exception
92. Collections
• A Sun aconselha sempre usar os
genéricos:
• Os códigos que não usam genérico
quando as classes o definem compilam,
mas geram warnings avisando que pode
dar problema.
93. Collections
• Mas perai e aqueles <?> o que é essa “?”
– Isso é um operador curinga ela funciona
quando você quer falar que aceita uma classe
com qualquer tipagem.
• Então:
Teste<?> tGenerico = new Teste<String>();
É o mesmo que ??
Teste tGenerico = new Teste<String>();
NÃO!! São diferentes!
94. Collections
• Mas perai e aqueles <?> o que é essa “?”
– Isso é um operador curinga ela funciona
quando você quer falar que aceita uma classe
com qualquer tipagem.
• Então:
Teste<?> tGenerico = new Teste<String>();
É o mesmo que ??
Teste tGenerico = new Teste<String>();
NÃO!! São diferentes!
95. Collections
• Mas perai e aqueles <?> o que é essa “?”
– Isso é um operador curinga ela funciona
quando você quer falar que aceita uma classe
com qualquer tipagem.
• Então:
ArrayList<?> c = new ArrayList<String>();
É o mesmo que ??
ArrayList c = new ArrayList<String>();
NÃO!! São diferentes!
96. Collections
• Mas perai e aqueles <?> o que é essa “?”
– Isso é um operador curinga ela funciona
quando você quer falar que aceita uma classe
com qualquer tipagem.
• Então:
ArrayList<?> c = new ArrayList<String>();
É o mesmo que ??
ArrayList c = new ArrayList<String>();
NÃO!! São diferentes!
97. Collections
• Quando você usa o operador <?> você
não pode mandar objetos para os
métodos tipados, por exemplo:
c.add(a); // não compila
• Todos os outros métodos, que não tem o
T, funcionam, portanto deve ser usando
quando você quer usar o objeto sem
passar objetos tipados, por exemplo:
c.size(); // funciona normalmente
98. Collections
• Tá ... e porque não compila ??
– O motivo é porque você não sabe que tipo de
coleção você esta trabalhando
• Por exemplo:
List<?> lista;
//eu posso adcionar qualquer lista ai
lista = new ArrayList<String>();
lista = new ArrayList<Integer>();
lista = new ArrayList<Thread>();
• Então quando você só sabe da list
• /
99. Collections
• Tá ... e porque não compila ??
– O motivo é porque você não sabe que tipo de
coleção você esta trabalhando
• Por exemplo:
List<?> lista;
//eu posso adcionar qualquer lista ai
lista = new ArrayList<String>();
lista = new ArrayList<Integer>();
lista = new ArrayList<Thread>();
• Então quando você só sabe da list
• /
100. Collections
• Tá ... e porque não compila ??
– O motivo é porque você não sabe que tipo de
coleção você esta trabalhando
• Por exemplo:
List<?> lista;
//eu posso adcionar qualquer lista ai
lista = new ArrayList<String>();
lista = new ArrayList<Integer>();
lista = new ArrayList<Thread>();
• Então quando você só sabe da list
• /
101. Collections
• Tá ... e porque não compila ??
– O motivo é porque você não sabe que tipo de
coleção você esta trabalhando
• Por exemplo:
List<?> lista;
//eu posso adcionar qualquer lista ai
lista = new ArrayList<String>();
lista = new ArrayList<Integer>();
lista = new ArrayList<Thread>();
• Então quando você só sabe da list
• /
102. Collections
• Tá ... e porque não compila ??
– O motivo é porque você não sabe que tipo de
coleção você esta trabalhando
• Por exemplo:
List<?> lista;
//eu posso adcionar qualquer lista ai
lista = new ArrayList<String>();
lista = new ArrayList<Integer>();
lista = new ArrayList<Thread>();
• Então quando você não sabe o tipo
• /
103. Collections
• Tá ... e porque não compila ??
– O motivo é porque você não sabe que tipo de
coleção você esta trabalhando
• Por exemplo:
List<?> lista = getList();
• Você não poderá saber o que essa lista aceita:
lista.add(“Texto”); //e se for uma lista de Thread ?
• Porem você pode usar os métodos não tipados
lista.contains(“Texto”);
lista.remove(33);
lista.size();
104. Collections
• Tá ... e porque não compila ??
– O motivo é porque você não sabe que tipo de
coleção você esta trabalhando
• Por exemplo:
List<?> lista = getList();
• Você não poderá saber o que essa lista aceita:
lista.add(“Texto”); //e se for uma lista de Thread ?
• Porem você pode usar os métodos não tipados
lista.contains(“Texto”);
lista.remove(33);
lista.size();
105. Collections
• Tá ... e porque não compila ??
– O motivo é porque você não sabe que tipo de
coleção você esta trabalhando
• Por exemplo:
List<?> lista = getList();
• Você não poderá saber o que essa lista aceita:
lista.add(“Texto”); //e se for uma lista de Thread ?
• Porem você pode usar os métodos não tipados
lista.contains(“Texto”);
lista.remove(33);
lista.size();
106. Collections
• Tá ... e porque não compila ??
– O motivo é porque você não sabe que tipo de
coleção você esta trabalhando
• Por exemplo:
List<?> lista = getList();
• Você não poderá saber o que essa lista aceita:
lista.add(“Texto”); //e se for uma lista de Thread ?
• Porem você pode usar os métodos não tipados
lista.contains(“Texto”);
lista.remove(33);
lista.size();
107. Collections
• Tá ... e porque não compila ??
– O motivo é porque você não sabe que tipo de
coleção você esta trabalhando
• Por exemplo:
List<?> lista = getList();
• Você não poderá saber o que essa lista aceita:
lista.add(“Texto”); //e se for uma lista de Thread ?
• Porem você pode usar os métodos não tipados
lista.contains(“Texto”);
Object o = lista.get(4); //n sei o tipo da lista .:. n sei o retorno
lista.size();
108. Collections
• Tá ... e porque não compila ??
– O motivo é porque você não sabe que tipo de
coleção você esta trabalhando
• Por exemplo:
List<?> lista = getList();
• Você não poderá saber o que essa lista aceita:
lista.add(“Texto”); //e se for uma lista de Thread ?
• Porem você pode usar os métodos não tipados
lista.contains(“Texto”);
Object o = lista.get(4); //n sei o tipo da lista .:. n sei o retorno
lista.size();
109. Collections
• Ta e aquele <? extends T> ?:
– Ele funciona como uma sub categoria... por exemplo:
ArrayList<Number> numbers = new ArrayList<Number>();
• O método addAll nesse caso fica
boolean addAll(Collection<? extends Number> c);
• E assim é possivel adcionar a numbers qualquer
coleção tipado como Number ou por de suas
subclasse.
ArrayList<Integer> integers = new ArrayList<Integer>();
integers.add(12); integers.add(15);
numbers.addAll(integers); //pois os inteiros também são Number
110. Collections
• Ta e aquele <? extends T> ?:
– Ele funciona como uma sub categoria... por exemplo:
ArrayList<Number> numbers = new ArrayList<Number>();
• O método addAll nesse caso fica
boolean addAll(Collection<? extends Number> c);
• E assim é possivel adcionar a numbers qualquer
coleção tipado como Number ou por de suas
subclasse.
ArrayList<Integer> integers = new ArrayList<Integer>();
integers.add(12); integers.add(15);
numbers.addAll(integers); //pois os inteiros também são Number
111. Collections
• Ta e aquele <? extends T> ?:
– Ele funciona como uma sub categoria... por exemplo:
ArrayList<Number> numbers = new ArrayList<Number>();
• O método addAll nesse caso fica
boolean addAll(Collection<? extends Number> c);
• E assim é possivel adcionar a numbers qualquer
coleção tipado como Number ou por de suas
subclasse.
ArrayList<Integer> integers = new ArrayList<Integer>();
integers.add(12); integers.add(15);
numbers.addAll(integers); //pois os inteiros também são Number
112. Collections
• Ta e aquele <? extends T> ?:
– Ele funciona como uma sub categoria... por exemplo:
ArrayList<Number> numbers = new ArrayList<Number>();
• O método addAll nesse caso fica
boolean addAll(Collection<? extends Number> c);
• E assim é possivel adcionar a numbers qualquer
coleção tipado como Number ou por de suas
subclasse.
ArrayList<Integer> integers = new ArrayList<Integer>();
integers.add(12); integers.add(15);
numbers.addAll(integers); //pois os inteiros também são Number
113. Collections
• Ta e aquele <? extends T> ?:
– Ele funciona como uma sub categoria... por exemplo:
ArrayList<Number> numbers = new ArrayList<Number>();
• O método addAll nesse caso fica
boolean addAll(Collection<? extends Number> c);
• E assim é possível adicionar a numbers
qualquer coleção tipado como Number ou por
uma de suas subclasse.
ArrayList<Integer> integers = new ArrayList<Integer>();
integers.add(12); integers.add(15);
numbers.addAll(integers); //pois os inteiros também são Number
114. Collections
• Ta e aquele <? extends T> ?:
– Ele funciona como uma sub categoria... por exemplo:
ArrayList<Number> numbers = new ArrayList<Number>();
• O método addAll nesse caso fica
boolean addAll(Collection<? extends Number> c);
• E assim é possível adicionar a numbers
qualquer coleção tipado como Number ou por
uma de suas subclasse.
ArrayList<Integer> integers = new ArrayList<Integer>();
integers.add(12); integers.add(15);
numbers.addAll(integers); //pois os inteiros também são Number
115. Collections
Espera um pouco!
• Ta e aquele <? extends T> ?:
É realmente necessário isso ??
– Ele funciona como uma sub categoria... por exemplo:
E se eu fizesse assim?
ArrayList<Number> numbers = new ArrayList<Number>();
• O método addAll nesse caso fica
boolean addAll(Collection<? extends Number> c);
• E assim é possível adicionar a numbers
qualquer coleção tipado como Number ou por
uma de suas subclasse.
ArrayList<Integer> integers = new ArrayList<Integer>();
integers.add(12); integers.add(15);
numbers.addAll(integers); //pois os inteiros também são Number
116. Collections
Espera um pouco!
• Ta e aquele <? extends T> ?:
É realmente necessário isso ??
– Ele funciona como uma sub categoria... por exemplo:
E se eu fizesse assim?
ArrayList<Number> numbers = new ArrayList<Number>();
• O método addAll nesse caso fica
boolean addAll(Collection<? extends Number> c);
• E assim é possível adicionar a numbers
qualquer coleção tipado como Number ou por
uma de SIM!!! Ésubclasse.
suas SIM!
ArrayList<Integer> integers = new ArrayList<Integer>();
Isso não será como você
integers.add(12); integers.add(15);
Espera, deixa eu explicar
numbers.addAll(integers); //pois os inteiros também são Number
melhor
117. Collections
Espera um pouco!
• Ta e aquele <? extends T> ?:
É realmente necessário isso ??
– Ele funciona como uma sub categoria... por exemplo:
E se eu fizer assim?
ArrayList<Number> numbers = new ArrayList<Number>();
• O método addAll nesse caso fica
boolean addAll(Collection<? extends Number> c);
• E assim é possível adicionar a numbers
(Collection<Number> c)
qualquer coleção tipado como Number ou por
uma de SIM!!! Ésubclasse.
suas SIM!
ArrayList<Integer> integers = new ArrayList<Integer>();
Isso não será como você
integers.add(12); integers.add(15);
Espera, deixa eu explicar
numbers.addAll(integers); //pois os inteiros também são Number
melhor
118. Collections
Espera um pouco!
• Ta e aquele <? extends T> ?:
É realmente necessário isso ??
– Ele funciona como uma sub categoria... por exemplo:
E se eu fizer assim?
ArrayList<Number> numbers = new ArrayList<Number>();
• O método addAll nesse caso fica
boolean addAll(Collection<? extends Number> c);
• E assim é possível adicionar a numbers
(Collection<Number> c)
qualquer coleção tipado como Number ou por
uma de SIM!!! Ésubclasse.
suas SIM!
ArrayList<Integer> integers = new ArrayList<Integer>();
Isso não será como você
integers.add(12); integers.add(15);
espera, deixa eu explicar
numbers.addAll(integers); //pois os inteiros também são Number
melhor
119. Collections
ArrayList<Number> list;
• Isso quer dizer que list só pode receber o tipo
Number... por exemplo:
list = new ArrayList<Integer>(); //NÃO compila
list = new ArrayList<Number>(); //compila
• Para ser qualquer sub-tipo de number é preciso
fazer
ArrayList<? extends Number> list;
list = new ArrayList<Integer>(); //agora compila
• E qual o retorno para list.get(0) ??
Number n = list.get(0); //O retorno é um Number!
120. Collections
ArrayList<Number> list;
• Isso quer dizer que list só pode receber o tipo
Number... por exemplo:
list = new ArrayList<Integer>(); // NÃO compila
list = new ArrayList<Number>(); // compila
• Para ser qualquer sub-tipo de number é preciso
fazer
ArrayList<? extends Number> list;
list = new ArrayList<Integer>(); //agora compila
• E qual o retorno para list.get(0) ??
Number n = list.get(0); //O retorno é um Number!
121. Collections
ArrayList<Number> list;
• Isso quer dizer que list só pode receber o tipo
Number... por exemplo:
list = new ArrayList<Integer>(); // NÃO compila
list = new ArrayList<Number>(); // compila
• Para ser qualquer sub-tipo de Number é preciso
fazer
ArrayList<? extends Number> list;
list = new ArrayList<Integer>(); //agora compila
• E qual o retorno para list.get(0) ??
Number n = list.get(0); //O retorno é um Number!
122. Collections
ArrayList<Number> list;
• Isso quer dizer que list só pode receber o tipo
Number... por exemplo:
list = new ArrayList<Integer>(); // NÃO compila
list = new ArrayList<Number>(); // compila
• Para ser qualquer sub-tipo de Number é preciso
fazer
ArrayList<? extends Number> list;
list = new ArrayList<Integer>(); //agora compila
• E qual o retorno para list.get(0) ??
Number n = list.get(0); //O retorno é um Number!
124. Collections
• Ta e aquele <T> T[] toArray(T[] a)?:
– Esse é um método generico, e não usa
tipagem da classe mas sim do método
125. Collections
• Ta e aquele <T> T[] toArray(T[] a)?:
– Esse é um método generico, e não usa
tipagem da classe mas sim do método
• Este método quer dizer que o retorno dele
é uma array do tipo “T” que é o mesmo
tipo da array enviada no argumento,
portanto
nums.toArray(new Number[])
nums.toArray(new Integer[])
126. Collections
• Ta e aquele <T> T[] toArray(T[] a)?:
– Esse é um método generico, e não usa
tipagem da classe mas sim do método
• Este método quer dizer que o retorno dele
é uma array do tipo “T” que é o mesmo
tipo da array enviada no argumento,
portanto
nums.toArray(new Number[]) // retorna um Number[]
nums.toArray(new Integer[])
127. Collections
• Ta e aquele <T> T[] toArray(T[] a)?:
– Esse é um método generico, e não usa
tipagem da classe mas sim do método
• Este método quer dizer que o retorno dele
é uma array do tipo “T” que é o mesmo
tipo da array enviada no argumento,
portanto
nums.toArray(new Number[])
nums.toArray(new Integer[]) // retorna um Integer[]
128. Collections
• Tem mais coisas que preciso saber sobre
Genéricos pra prova ou para usar
collection??
129. Collections
• Tem mais coisas que preciso saber sobre
Genéricos pra prova ou para usar
collection??
– SIM! Tem, é só mais uma coisa, que eu vou
explicar depois!
130. Collections
• Tem mais coisas que preciso saber sobre
Genéricos pra prova ou para usar
collection??
– SIM! Tem, é só mais uma coisa, que eu vou
explicar depois!
• Mas vamos voltar para collections se não
agente não acaba!
132. Collections
• A java.util.Collection:
– Collection é um contrato de interface que
representa uma coleção de objetos
– Pode-se dizer que uma coleção é uma versão
turbinada de array, com mais funcionalidades
e mais segurança.
133. Collections
• Métodos java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c)
boolean retainAll(Collection<?> c)
void clear()
boolean contains(Object o)
boolean containsAll(Collection<?> c)
int size()
boolean isEmpty()
Object[] toArray()
<T> T[] toArray(T[] a)
Iterator<E> iterator() //método de Iterable
134. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c)
boolean retainAll(Collection<?> c)
void clear() Opcional
boolean contains(Object o)
boolean containsAll(Collection<?> c)
int size()
boolean isEmpty()
Object[] toArray()
<T> T[] toArray(T[] a)
Iterator<E> iterator()
135. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c) COMO ASSIM OPCIONAL?
boolean remove(Object o)
boolean removeAll(Collection<?> c)
boolean retainAll(Collection<?> c)
void clear() Opcional
boolean contains(Object o)
boolean containsAll(Collection<?> c)
int size()
boolean isEmpty()
Object[] toArray()
<T> T[] toArray(T[] a)
Iterator<E> iterator()
136. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c) COMO ASSIM OPCIONAL?
boolean remove(Object o)
boolean removeAll(Collection<?> c) A interface pede o método,
como vocês podem ver,
boolean retainAll(Collection<?> c) porém na implementação
void clear() Opcional pode-se lançar a exceção
UnsupportedOperationException
boolean contains(Object o) E isso é utilizado em
boolean containsAll(Collection<?> c) Implementações somente leitura
Implementações boca de lobo
int size() ou outros tipos.
boolean isEmpty()
Object[] toArray()
<T> T[] toArray(T[] a)
Iterator<E> iterator()
137. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c)
boolean retainAll(Collection<?> c)
void clear()
boolean contains(Object o)
boolean containsAll(Collection<?> c)
int size() Vamos conhecer os métodos!
boolean isEmpty()
Object[] toArray()
<T> T[] toArray(T[] a)
Iterator<E> iterator()
138. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Adiciona um elemento a
boolean retainAll(Collection<?> c) coleção, onde este elemento
void clear() deve ser do mesmo tipo <E>
boolean contains(Object o) da coleção, ou de um sub-tipo.
boolean containsAll(Collection<?> c) Retorna verdadeiro se houver
int size() modificação na coleção, ou
boolean isEmpty() seja se o elemento for
adicionado.
Object[] toArray()
<T> T[] toArray(T[] a)
Implementação é opcional
Iterator<E> iterator()
139. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Adiciona uma coleção de
boolean retainAll(Collection<?> c) elementos do mesmo tipo <E>
void clear() ou uma coleção de sub-tipos
boolean contains(Object o) de <E>.
boolean containsAll(Collection<?> c) Retorna verdadeiro se pelo
int size() menos um elemento for
boolean isEmpty() adicionado a coleção, ou seja,
se a coleção foi modificada.
Object[] toArray()
<T> T[] toArray(T[] a)
Implementação é opcional
Iterator<E> iterator()
140. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Remove da coleção a primeira
boolean retainAll(Collection<?> c) ocorrência de um objeto
void clear() significantemente igual ao
boolean contains(Object o) enviado.
boolean containsAll(Collection<?> c) Retorna verdadeiro caso o
int size() objeto existia na coleção, ou
boolean isEmpty() seja, se a coleção foi
modificada.
Object[] toArray()
<T> T[] toArray(T[] a)
Implementação é opcional.
Iterator<E> iterator()
141. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Remove todas da as
boolean retainAll(Collection<?> c) ocorrências desta coleção dos
void clear() elementos contidos na coleção
boolean contains(Object o) c enviada.
boolean containsAll(Collection<?> c) Após esta operação nenhum
int size() elemento desta coleção
boolean isEmpty() retornará true para c.contains()
Retorna verdadeiro se pelo
Object[] toArray()
menos um elemento foi
<T> T[] toArray(T[] a)
removido, ou seja, se a
Iterator<E> iterator()
coleção foi modificada.
Implementação é opcional.
142. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Faz o processo inverso de
boolean retainAll(Collection<?> c) removeAll.
void clear() Retém nesta coleção apénas
boolean contains(Object o) os elementos que também
boolean containsAll(Collection<?> c) estejam continos na coleção c.
int size() Após esta operação todos os
boolean isEmpty() elementos desta coleção
retornarão true para
Object[] toArray()
c.contains().
<T> T[] toArray(T[] a)
Retorna verdadeiro se a
Iterator<E> iterator()
coleção for modificada.
Implementação é opcional
143. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Remove todos os elementos
boolean retainAll(Collection<?> c) da coleção
void clear()
boolean contains(Object o) Implementação é opcional.
boolean containsAll(Collection<?> c)
int size()
boolean isEmpty()
Object[] toArray()
<T> T[] toArray(T[] a)
Iterator<E> iterator()
144. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Verifica se existe nesta coleção
boolean retainAll(Collection<?> c) um objeto significantemente
void clear() igual ao objeto o enviado.
boolean contains(Object o)
boolean containsAll(Collection<?> c)
int size()
boolean isEmpty()
Object[] toArray()
<T> T[] toArray(T[] a)
Iterator<E> iterator()
145. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Verifica se todos os objetos da
boolean retainAll(Collection<?> c) coleção c enviada, estão
void clear() contidos nesta coleção.
boolean contains(Object o) Só retorna verdade se
boolean containsAll(Collection<?> c) this.contains(elementoDeC) for
int size() verdade para cada elemento
boolean isEmpty() de c.
Object[] toArray()
<T> T[] toArray(T[] a)
Iterator<E> iterator()
146. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Informa a quantidade de
boolean retainAll(Collection<?> c) objetos contidos na coleção.
void clear() Obs.: Se a coleção contiver
boolean contains(Object o) objetos nulos eles também
boolean containsAll(Collection<?> c) serão contabilizados
int size()
boolean isEmpty() Sim! Existem coleções que
aceitam elementos nulos.
Object[] toArray()
<T> T[] toArray(T[] a)
Iterator<E> iterator()
147. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Método de comodidade, o
boolean retainAll(Collection<?> c) mesmo que testar se:
void clear() size() == 0
boolean contains(Object o) Retorna verdadeiro se não
boolean containsAll(Collection<?> c) houver elementos nesta
int size() coleção.
boolean isEmpty()
Object[] toArray()
<T> T[] toArray(T[] a)
Iterator<E> iterator()
148. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Retorna uma array contendo
boolean retainAll(Collection<?> c) cada um dos elementos desta
void clear() coleção, na mesma ordem em
boolean contains(Object o) que os elementos aparecem
boolean containsAll(Collection<?> c) no iterator().
int size() Não é a array mantida pela
boolean isEmpty() lista (caso assim seja
implementada) é uma cópia
Object[] toArray()
dela.
<T> T[] toArray(T[] a)
Alterações nesta array não são
Iterator<E> iterator()
refletidas na coleção.
149. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Retorna todos os elementos da
boolean retainAll(Collection<?> c) coleção em uma array do
void clear() mesmo tipo da enviada.
boolean contains(Object o) if (a.length >= this.size()) {
boolean containsAll(Collection<?> c) Então os elementos serão
int size() colocados dentro da própria
boolean isEmpty() array enviada e os elementos
que sobrarem serão setados
Object[] toArray()
null.
<T> T[] toArray(T[] a)
} else {
Iterator<E> iterator()
cria uma nova array do mesmo
tipo da enviada e a retorna.
150. Collections
• java.util.Collection<E> extends Iterable<E>:
boolean add(E e)
boolean addAll(Collection<? extends E> c)
boolean remove(Object o)
boolean removeAll(Collection<?> c) Cria um Iterator que é usado
boolean retainAll(Collection<?> c) para navegar sobre os
void clear() elementos desta coleção
boolean contains(Object o) public interface Iterator<E> {
boolean containsAll(Collection<?> c) boolean hasNext();
int size() E next();
boolean isEmpty() void remove(); //opicional
}
Object[] toArray()
* Este método é parte da
<T> T[] toArray(T[] a)
interface Iterable<E> e toda
Iterator<E> iterator() //*
classe que a implementa pode
ser usada em um for-each
152. Collections
• java.util.Collection<E>:
– Não há restrição, ordem ou classificação
definida no contrato de Collection
– A coleção de objetos pode conter qualquer
tipo de objeto, em qualquer quantidade,
sejam eles repetidos ou não, sem qualquer
ordem ou classificação definida.
153. Collections
• java.util.Collection<E>:
– Não há restrição, ordem ou classificação
definida no contrato de Collection
– A coleção de objetos pode conter qualquer
tipo de objeto, em qualquer quantidade,
sejam eles repetidos ou não, sem qualquer
ordem ou classificação definida.
– Esta é a forma mais genérica de agrupar
objetos
154. Collections
• Tá! e se eu quiser uma coleção sem
deixar que os objetos se repitam ??
155. Collections
• Tá! e se eu quiser uma coleção sem
deixar que os objetos se repitam ??
– Então você quer um java.util.Set uma sub-
interface de Collection
156. Collections
• java.util.Set<E> extends Collection<E>:
– Um Set tem exatamente a mesma interface de
Collection, a única mudança é na descrição de seus
métodos.
– O Set não aceita elementos repetidos
– Ao usar add(obj) onde o Set já contem obj, ele
simplesmente não o adiciona e retorna false.
– A não implementação de equals(Object o) ou a
implementação incorreta pode causar efeitos
indesejáveis e bug de difícil detectação.
157. Collections
• java.util.Set<E> extends Collection<E>:
– Um Set tem exatamente a mesma interface de
Collection, a única mudança é na descrição de seus
métodos.
– O Set não aceita elementos repetidos
– Ao usar add(obj) onde o Set já contem obj, ele
simplesmente não o adiciona e retorna false.
– A não implementação de equals(Object o) ou a
implementação incorreta pode causar efeitos
indesejáveis e bug de difícil detectação.
158. Collections
• java.util.Set<E> extends Collection<E>:
– Um Set tem exatamente a mesma interface de
Collection, a única mudança é na descrição de seus
métodos.
– O Set não aceita elementos repetidos
– Ao usar add(obj) onde o Set já contem obj, ele
simplesmente não o adiciona e retorna false.
– A não implementação de equals(Object o) ou a
implementação incorreta pode causar efeitos
indesejáveis e bug de difícil detectação.
159. Collections
• java.util.Set<E> extends Collection<E>:
– Assim como a Collection, não há restrição, ordem ou
classificação definida no contrato de Set
– A coleção de objetos pode conter qualquer tipo de
objeto, em qualquer quantidade, sem qualquer ordem
ou classificação definida, porem nunca objetos
repetidos!
– Este é o diferencial de um Set para uma Collection,
não há objetos significantemente repetidos, isso
quer dizer onde equals(other) retorne true para outro
elemento dentro do mesmo Set.
160. Collections
• java.util.Set<E> extends Collection<E>:
– Assim como a Collection, não há restrição, ordem ou
classificação definida no contrato de Set
– A coleção de objetos pode conter qualquer tipo de
objeto, em qualquer quantidade, sem qualquer ordem
ou classificação definida, porem nunca objetos
repetidos!
– Este é o diferencial de um Set para uma Collection,
não há objetos significantemente repetidos, isso
quer dizer onde equals(other) retorne true para outro
elemento dentro do mesmo Set.
161. Collections
• java.util.Set<E> extends Collection<E>:
– Assim como a Collection, não há restrição, ordem ou
classificação definida no contrato de Set
– A coleção de objetos pode conter qualquer tipo de
objeto, em qualquer quantidade, sem qualquer ordem
ou classificação definida, porem nunca objetos
repetidos!
– Este é o diferencial de um Set para uma Collection,
não há objetos significantemente repetidos, isso
quer dizer onde equals(other) retorne true para outro
elemento dentro do mesmo Set.
162. Collections
• É possível também utilizar os conceitos de
fila com a Java Collections Framework
– Através da interface java.util.Queue<E>
163. Collections
• java.util.Queue<E> extends Collection<E>:
– Assim como a Collection, não há restrição, ordem ou
classificação definida no contrato da fila Queue
– Há apenas disponibilizado uma interface de fila,
sem especificar quais condições.
– As suas implementações que vão definir se a Queue
é uma FIFO, FILO ou o quer que seja.
164. Collections
• java.util.Queue<E> extends Collection<E>:
– Assim como a Collection, não há restrição, ordem ou
classificação definida no contrato da fila Queue
– Há apenas disponibilizado uma interface de fila,
sem especificar quais condições.
– As suas implementações que vão definir se a Queue
é uma FIFO, FILO ou o quer que seja.
165. Collections
• java.util.Queue<E> extends Collection<E>:
– Assim como a Collection, não há restrição, ordem ou
classificação definida no contrato da fila Queue
– Há apenas disponibilizado uma interface de fila,
sem especificar quais condições.
– As suas implementações que vão definir se a Queue
é uma FIFO, FILO ou o quer que seja.
166. Collections
• java.util.Queue<E> extends Collection<E>:
boolean add(E e) //adciona um elemento a fila se houver capacidade,
//lança uma IllegalStateException se não houver.
boolean offer(E e) //adciona um elemento a fila se houver capacidade,
//retorna false (sem lança exceção) se não houver.
E element() //retorna, mas não remove o elemento do topo da fila
//lança uma exceção se não houver mais elementos
E peek() //retorna, mas não remove o elemento do topo da fila
//retorna null se não houver elementos.
E remove() //retorna e remove o elemento do topo da fila
//lança uma exceção se não houver mais elementos.
E poll() //retorna e remove o elemento do topo da fila
//retorna null se não houver elementos.
167. Collections
• java.util.Queue<E> extends Collection<E>:
boolean add(E e) //adiciona um elemento a fila se houver capacidade,
// se não houver lança uma IllegalStateException.
boolean offer(E e) //adiciona um elemento a fila se houver capacidade,
// se não houver retorna false (sem lança exceção).
E element() //retorna, mas não remove o elemento do topo da fila
//lança uma exceção se não houver mais elementos.
E peek() //retorna, mas não remove o elemento do topo da fila
//retorna null se não houver elementos.
E remove() //retorna e remove o elemento do topo da fila
//lança uma exceção se não houver mais elementos.
E poll() //retorna e remove o elemento do topo da fila
//retorna null se não houver elementos.
168. Collections
• java.util.Queue<E> extends Collection<E>:
boolean add(E e) //adiciona um elemento a fila se houver capacidade,
// se não houver lança uma IllegalStateException.
boolean offer(E e) //adiciona um elemento a fila se houver capacidade,
// se não houver retorna false (sem lança exceção).
E element() //retorna, mas não remove o elemento do topo da fila
//não havendo + elementos lança NoSuchElementException.
E peek() //retorna, mas não remove o elemento do topo da fila
//retorna null se não houver elementos.
E remove() //retorna e remove o elemento do topo da fila
//lança uma exceção se não houver mais elementos.
E poll() //retorna e remove o elemento do topo da fila
//retorna null se não houver elementos.
169. Collections
• java.util.Queue<E> extends Collection<E>:
boolean add(E e) //adiciona um elemento a fila se houver capacidade,
// se não houver lança uma IllegalStateException.
boolean offer(E e) //adiciona um elemento a fila se houver capacidade,
// se não houver retorna false (sem lança exceção).
E element() //retorna, mas não remove o elemento do topo da fila
//não havendo + elementos lança NoSuchElementException.
E peek() //retorna, mas não remove o elemento do topo da fila
//retorna null se não houver elementos.
E remove() //retorna e remove o elemento do topo da fila
//não havendo + elementos lança NoSuchElementException.
E poll() //retorna e remove o elemento do topo da fila
//retorna null se não houver elementos.
170. Collections
• Mas e como eu consigo verificar o elemento 4
que esta dentro de uma Collection, Queue ou
Set? só da usando o iterator() ?
– Sim infelizmente sim, a única forma de verificar os
elementos destas duas interfaces é percorrendo a
coleção toda!
• Putz! E aquele papo de que era uma array
turbinada?? Não tem índice ?
– Para tudo na vida tem uma solução, o que você quer
é uma java.util.List
171. Collections
• Mas e como eu consigo verificar o elemento 4
que esta dentro de uma Collection, Queue ou
Set? só da usando o iterator() ?
– Sim infelizmente sim, a única forma de verificar os
elementos destas interfaces é percorrendo a coleção
toda!
• Putz! E aquele papo de que era uma array
turbinada?? Não tem índice ?
– Para tudo na vida tem uma solução, o que você quer
é uma java.util.List
172. Collections
• Mas e como eu consigo verificar o elemento 4
que esta dentro de uma Collection, Queue ou
Set? só da usando o iterator() ?
– Sim infelizmente sim, a única forma de verificar os
elementos destas interfaces é percorrendo a coleção
toda!
• Putz! E aquele papo de que era uma array
turbinada?? Não tem índice ? cadê o get(3) ?
– Para tudo na vida tem uma solução, o que você quer
é uma java.util.List
173. Collections
• Mas e como eu consigo verificar o elemento 4
que esta dentro de uma Collection, Queue ou
Set? só da usando o iterator() ?
– Sim infelizmente sim, a única forma de verificar os
elementos destas interfaces é percorrendo a coleção
toda!
• Putz! E aquele papo de que era uma array
turbinada?? Não tem índice ? cadê o get(3) ?
– Para tudo na vida tem uma solução, o que você quer
é uma java.util.List<E>
174. Collections
• java.util.List<E> extends Collection<E>:
– Uma List é uma coleção ordenada (não classificada), muito
parecida com arrays, porem com bem mais funcionalidades e
sem limite de tamanho.
– Os métodos add() e addAll() da interface Collection adicionam
itens ao final da List.
– Assim como as Collection todos os métodos de adição e
remoção são opcionais e podem lançar
UnsupportedOperationException
– As mudanças principais em relação a Collection é que tem seus
itens ordenado. Os itens da List são ordenados em índice
que vão de 0 a (size() -1), conformes veremos a seguir, e usar
índice fora desse range gera IndexOutOfBoundsException.
175. Collections
• java.util.List<E> extends Collection<E>:
– Uma List é uma coleção ordenada (não classificada), muito
parecida com arrays, porem com bem mais funcionalidades e
sem limite de tamanho.
– Os métodos add() e addAll() da interface Collection adicionam
itens ao final da List.
– Assim como as Collection todos os métodos de adição e
remoção são opcionais e podem lançar
UnsupportedOperationException
– As mudanças principais em relação a Collection é que tem seus
itens ordenado. Os itens da List são ordenados em índice
que vão de 0 a (size() -1), conformes veremos a seguir, e usar
índice fora desse range gera IndexOutOfBoundsException.
176. Collections
• java.util.List<E> extends Collection<E>:
– Uma List é uma coleção ordenada (não classificada), muito
parecida com arrays, porem com bem mais funcionalidades e
sem limite de tamanho.
– Os métodos add() e addAll() da interface Collection adicionam
itens ao final da List.
– Assim como as Collection todos os métodos de adição e
remoção são opcionais e podem lançar
UnsupportedOperationException
– As mudanças principais em relação a Collection é que tem seus
itens ordenado. Os itens da List são ordenados em índice
que vão de 0 a (size() -1), conformes veremos a seguir, e usar
índice fora desse range gera IndexOutOfBoundsException.
177. Collections
• java.util.List<E> extends Collection<E>:
– Uma List é uma coleção ordenada (não classificada), muito
parecida com arrays, porem com bem mais funcionalidades e
sem limite de tamanho.
– Os métodos add() e addAll() da interface Collection adicionam
itens ao final da List.
– Assim como as Collection todos os métodos de adição e
remoção são opcionais e podem lançar
UnsupportedOperationException
– As mudanças principais em relação a Collection é que tem seus
itens ordenado. Os itens da List são ordenados em índice
que vão de 0 a (size() -1), conformes veremos a seguir, e usar
índice fora desse range gera IndexOutOfBoundsException.
178. Collections
• java.util.List<E> extends Collection<E>:
– Uma List é uma coleção ordenada (não classificada), muito
parecida com arrays, porem com bem mais funcionalidades e
sem limite de tamanho.
– Os métodos add() e addAll() da interface Collection adicionam
itens ao final da List.
– Assim como as Collection todos os métodos de adição e
remoção são opcionais e podem lançar
UnsupportedOperationException
– As mudanças principais em relação a Collection é que tem seus
itens ordenado. Os itens da List são ordenados em índice que
vão de 0 a (size() -1), conformes veremos a seguir, e usar índice
fora desse range gera IndexOutOfBoundsException.
179. Collections
• java.util.List<E> extends Collection<E>:
boolean add(int i, E e)
boolean addAll(int i, Collection<? extends E> c)
E get(int i)
int indexOf(Object o)
int lastIndexOf(Object o)
ListIterator<E> listIterator()
ListIterator<E> listIterator(int i)
E remove(int i)
E set(int index, E element)
List<E> subList(int fromIndex, int toIndex)
180. Collections
• java.util.List<E> extends Collection<E>:
boolean add(int i, E e)
boolean addAll(int i, Collection<? extends E> c)
E get(int i)
int indexOf(Object o) Adiciona o elemento e na posição
de índice i. Se houver, o antigo
int lastIndexOf(Object o)
elemento do índice e seus
ListIterator<E> listIterator() posteriores terão seus índices
ListIterator<E> listIterator(int i) incrementados
E remove(int i)
E set(int index, E element)
List<E> subList(int fromIndex, int toIndex)
181. Collections
• java.util.List<E> extends Collection<E>:
boolean add(int i, E e)
boolean addAll(int i, Collection<? extends E> c)
E get(int i)
int indexOf(Object o) Adiciona os elemento de c na
posição de índice i. Se houver, o
int lastIndexOf(Object o)
antigo elemento do índice e seus
ListIterator<E> listIterator() posteriores terão seus índices
ListIterator<E> listIterator(int i) incrementados em c.size()
E remove(int i)
E set(int index, E element)
List<E> subList(int fromIndex, int toIndex)
182. Collections
• java.util.List<E> extends Collection<E>:
boolean add(int i, E e)
boolean addAll(int i, Collection<? extends E> c)
E get(int i)
int indexOf(Object o) Retorna o elemento do índice i
int lastIndexOf(Object o)
ListIterator<E> listIterator()
ListIterator<E> listIterator(int i)
E remove(int i)
E set(int index, E element)
List<E> subList(int fromIndex, int toIndex)
183. Collections
• java.util.List<E> extends Collection<E>:
boolean add(int i, E e)
boolean addAll(int i, Collection<? extends E> c)
E get(int i)
int indexOf(Object o) Retorna o índice do primeiro
objeto da list igual ao enviado ou
int lastIndexOf(Object o)
-1 caso não exista o objeto na
ListIterator<E> listIterator() coleção.
ListIterator<E> listIterator(int i)
E remove(int i)
E set(int index, E element)
List<E> subList(int fromIndex, int toIndex)
184. Collections
• java.util.List<E> extends Collection<E>:
boolean add(int i, E e)
boolean addAll(int i, Collection<? extends E> c)
E get(int i)
int indexOf(Object o) Retorna o índice do ultimo objeto
da list igual ao enviado ou -1 caso
int lastIndexOf(Object o)
não exista o objeto na coleção.
ListIterator<E> listIterator()
ListIterator<E> listIterator(int i)
E remove(int i)
E set(int index, E element)
List<E> subList(int fromIndex, int toIndex)
185. Collections
• java.util.List<E> extends Collection<E>:
boolean add(int i, E e)
boolean addAll(int i, Collection<? extends E> c)
E get(int i)
int indexOf(Object o) Retorna um ListIterator desta List.
Este objeto é uma extensão do
int lastIndexOf(Object o)
Iterator, com a diferença que
ListIterator<E> listIterator() você pode caminhar p/ frente ou
ListIterator<E> listIterator(int i) p/ traz na lista, alem de adicionar
E remove(int i) e alterar elementos no índice
corrente.
E set(int index, E element)
List<E> subList(int fromIndex, int toIndex)
186. Collections
• java.util.List<E> extends Collection<E>:
public interface ListIterator<E>
extends Iterator<E> {
boolean hasNext() Retorna um ListIterator desta List.
E next() Este objeto é uma extensão do
int nextIndex() Iterator, com a diferença que
boolean hasPrevious() você pode caminhar p/ frente ou
E previous() p/ traz na lista, alem de adicionar
int previousIndex() e alterar elementos no índice
void add(E e) corrente.
void set(E e)
void remove()
}
187. Collections
• java.util.List<E> extends Collection<E>:
public interface ListIterator<E>
extends Iterator<E> {
boolean hasNext() Verifica se há um próximo
E next() elemento na List.
int nextIndex()
boolean hasPrevious()
E previous()
int previousIndex()
void add(E e)
void set(E e)
void remove()
}
188. Collections
• java.util.List<E> extends Collection<E>:
public interface ListIterator<E>
extends Iterator<E> {
boolean hasNext() Retorna o próximo elemento da
E next() List.
int nextIndex()
boolean hasPrevious() Se não houver o próximo
E previous() elemento uma
int previousIndex() NoSuchElementException é
void add(E e) lançada.
void set(E e)
void remove()
}
189. Collections
• java.util.List<E> extends Collection<E>:
public interface ListIterator<E>
extends Iterator<E> {
boolean hasNext() Retorna o índice do próximo
E next() elemento da List.
int nextIndex()
boolean hasPrevious() Se não houver um próximo
E previous() elemento retorna o tamanha da
int previousIndex() lista, ou seja, o mesmo que
void add(E e) lista.size().
void set(E e)
void remove()
}
190. Collections
• java.util.List<E> extends Collection<E>:
public interface ListIterator<E>
extends Iterator<E> {
boolean hasNext() Verifica se há um elemento
E next() anterior na List.
int nextIndex()
boolean hasPrevious()
E previous()
int previousIndex()
void add(E e)
void set(E e)
void remove()
}
191. Collections
• java.util.List<E> extends Collection<E>:
public interface ListIterator<E>
extends Iterator<E> {
boolean hasNext() Retorna o elemento anterior da
E next() List.
int nextIndex()
boolean hasPrevious() Se não houver o elemento
E previous() anterior uma
int previousIndex() NoSuchElementException é
void add(E e) lançada.
void set(E e)
void remove()
}
192. Collections
• java.util.List<E> extends Collection<E>:
public interface ListIterator<E>
extends Iterator<E> {
boolean hasNext() Retorna o índice do elemento
E next() anterior da List.
int nextIndex()
boolean hasPrevious() Se não houver um elemento
E previous() anterior retorna -1.
int previousIndex()
void add(E e)
void set(E e)
void remove()
}
193. Collections
• java.util.List<E> extends Collection<E>:
public interface ListIterator<E>
extends Iterator<E> {
boolean hasNext() Adiciona o elemento e a List no
E next() índice atual, entre nextIndex() e
int nextIndex() previousIndex().
boolean hasPrevious()
E previous()
int previousIndex()
void add(E e)
void set(E e)
void remove()
}
194. Collections
• java.util.List<E> extends Collection<E>:
public interface ListIterator<E>
extends Iterator<E> {
boolean hasNext() Substitui o último elemento
E next() retornado por next ou previous.
int nextIndex()
boolean hasPrevious() Se anteriormente next / previous
E previous() não foi chamado ou add / remove
int previousIndex() foi invocado será lançada uma
void add(E e) IllegalStateException
void set(E e)
void remove()
}
195. Collections
• java.util.List<E> extends Collection<E>:
public interface ListIterator<E>
extends Iterator<E> {
boolean hasNext() Remove o último elemento
E next() retornado por next ou previous.
int nextIndex()
boolean hasPrevious() Se anteriormente next / previous
E previous() não foi chamado ou add / remove
int previousIndex() foi invocado será lançada uma
void add(E e) IllegalStateException
void set(E e)
void remove()
}
196. Collections
• java.util.List<E> extends Collection<E>:
boolean add(int i, E e)
boolean addAll(int i, Collection<? extends E> c)
E get(int i)
int indexOf(Object o) Igual ao método anterior com a
diferença que o índice corrente
int lastIndexOf(Object o)
do ListIterator será o índice
ListIterator<E> listIterator() passado.
ListIterator<E> listIterator(int i) Obs.: é possível retornar para
E remove(int i) antes do índice passado.
E set(int index, E element)
List<E> subList(int fromIndex, int toIndex)
197. Collections
• java.util.List<E> extends Collection<E>:
boolean add(int i, E e)
boolean addAll(int i, Collection<? extends E> c)
E get(int i)
int indexOf(Object o) Remove o elemento de índice i da
List e o retorna. Importante!!!
int lastIndexOf(Object o) Integer indexA = 1; int indexB = 1;
ListIterator<E> listIterator() list.remove(indexA)
list.remove(indexB)
ListIterator<E> listIterator(int i) são operações totalmente diferentes
E remove(int i) O 1° remove um objeto Integer == 1
O 2° remove o objeto no índice 1
E set(int index, E element)
List<E> subList(int fromIndex, int toIndex)
198. Collections
• java.util.List<E> extends Collection<E>:
boolean add(int i, E e)
boolean addAll(int i, Collection<? extends E> c)
E get(int i)
int indexOf(Object o) Substitui o objeto no índice index
pelo element enviado e retorna o
int lastIndexOf(Object o)
objeto substituído.
ListIterator<E> listIterator()
ListIterator<E> listIterator(int i)
E remove(int i)
E set(int index, E element)
List<E> subList(int fromIndex, int toIndex)
199. Collections
• java.util.List<E> extends Collection<E>:
boolean add(int i, E e)
boolean addAll(int i, Collection<? extends E> c)
E get(int i)
int indexOf(Object o) Retorna o elemento do índice
fromIndex (inclusive) até os
int lastIndexOf(Object o) elementos de índice toIndex
ListIterator<E> listIterator() (exclusive). Mudança na subList são
refletidas na List original, o contrario
ListIterator<E> listIterator(int i) impossibilita o uso da subList, que, se
E remove(int i) usada, lançará
ConcurrentModificationException
E set(int index, E element)
List<E> subList(int fromIndex, int toIndex)
200. Collections
• Ok, mas existe alguma forma de criar
Coleções classificadas ?
– Sim!!
• Mas antes de vermos como manter listas
classificadas precisamos conhecer duas
interfaces Comparator<T> e
Comparable<T>
• Estas duas interfaces indicam a ordem de
classificação dos objetos
201. Collections
• Ok, mas existe alguma forma de criar
Coleções classificadas ?
– Sim!!
• Mas antes de vermos como manter listas
classificadas precisamos conhecer duas
interfaces Comparator<T> e
Comparable<T>
• Estas duas interfaces indicam a ordem de
classificação dos objetos
202. Collections
• Ok, mas existe alguma forma de criar
Coleções classificadas ?
– Sim!!
• Mas antes de vermos como manter listas
classificadas precisamos conhecer duas
interfaces Comparator<T> e
Comparable<T>
• Estas duas interfaces indicam a ordem de
classificação dos objetos
203. Collections
• Ok, mas existe alguma forma de criar
Coleções classificadas ?
– Sim!!
• Mas antes de vermos como manter listas
classificadas precisamos conhecer duas
interfaces Comparator<T> e
Comparable<T>
• Estas duas interfaces indicam a ordem de
classificação dos objetos
204. Collections
• Comparable<T> é uma interface que só tem um método:
int compareTo(T o)
– Retorna negativo, zero, ou positivo quando este objeto é menor
que, igual que ou maior que, respectivamente.
• Objetos que tem ordem natural implementam esta
interface, por exemplo:
String texto1 = “dado”, texto2 = “morta”;
if (texto1.compareTo(texto2) < 0) {
System.out.println(“texto1 vem 1°”);
} else if (texto1.compareTo(texto2) > 0) {
System.out.println(“texto1 vem 2°”);
}
205. Collections
• Comparable<T> é uma interface que só tem um método:
int compareTo(T o)
– Retorna negativo, zero, ou positivo quando este objeto é menor
que, igual que ou maior que, respectivamente.
• Objetos que tem ordem natural implementam esta
interface... por exemplo:
String texto1 = “dado”, texto2 = “morta”;
if (texto1.compareTo(texto2) < 0) {
System.out.println(“texto1 vem 1°”);
} else if (texto1.compareTo(texto2) > 0) {
System.out.println(“texto1 vem 2°”);
}
206. Collections
• Comparable<T> é uma interface que só tem um método:
int compareTo(T o)
– Retorna negativo, zero, ou positivo quando este objeto é menor
que, igual que ou maior que, respectivamente.
• Objetos que tem ordem natural implementam esta
interface... por exemplo:
String texto1 = “dado”, texto2 = “morta”;
if (texto1.compareTo(texto2) < 0) {
System.out.println(“texto1 vem 1°”);
} else if (texto1.compareTo(texto2) > 0) {
System.out.println(“texto1 vem 2°”);
}
207. Collections
• Comparable<T> é uma interface que só tem um método:
int compareTo(T o)
– Retorna negativo, zero, ou positivo quando este objeto é menor
que, igual que ou maior que, respectivamente.
• Objetos que tem ordem natural implementam esta
interface... por exemplo:
String texto1 = “dado”, texto2 = “morta”;
if (texto1.compareTo(texto2) < 0) {
System.out.println(“texto1 vem 1°”); // imprime este
} else if (texto1.compareTo(texto2) > 0) {
System.out.println(“texto1 vem 2°”);
}