Este documento fornece uma introdução às coleções no Java, discutindo os seguintes pontos:
1) A importância de entender igualdade no Java para trabalhar com coleções;
2) Como sobrescrever corretamente o método equals para definir a igualdade entre objetos;
3) Como o método hashCode está ligado ao equals e também deve ser sobrescrito.
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°”);
}