Não precisar fazer o typecast é uma das maiores vantagens dos genéricos Java , pois ele executa a verificação de tipo em tempo de compilação. Isso reduzirá a possibilidade de ClassCastExceptions que podem ser lançados no tempo de execução e podem levar a um código mais robusto.
Mas suspeito que você esteja totalmente ciente disso.
Cada vez que vejo os Genéricos, fico com dor de cabeça. Acho que a melhor parte do Java é sua simplicidade e sintaxe mínima e genéricos não são simples e adicionam uma quantidade significativa de nova sintaxe.
No início, também não vi o benefício dos genéricos. Comecei a aprender Java a partir da sintaxe 1.4 (embora Java 5 estivesse lançado na época) e quando encontrei genéricos, senti que era mais código para escrever e realmente não entendi os benefícios.
IDEs modernos facilitam a escrita de código com genéricos.
A maioria dos IDEs modernos e decentes são inteligentes o suficiente para ajudar a escrever código com genéricos, especialmente com o auto-completar de código.
Aqui está um exemplo de como fazer um Map<String, Integer>com a HashMap. O código que eu teria que digitar é:
Map<String, Integer> m = new HashMap<String, Integer>();
E, de fato, é muito digitar apenas para fazer um novo HashMap. No entanto, na realidade, eu só tive que digitar isso antes que o Eclipse soubesse o que eu precisava:
Map<String, Integer> m = new Ha Ctrl+Space
Verdade, eu precisava selecionar HashMapem uma lista de candidatos, mas basicamente o IDE sabia o que adicionar, incluindo os tipos genéricos. Com as ferramentas certas, usar genéricos não é tão ruim.
Além disso, como os tipos são conhecidos, ao recuperar elementos da coleção genérica, o IDE agirá como se aquele objeto já fosse um objeto de seu tipo declarado - não há necessidade de cast para o IDE saber qual o tipo do objeto é.
Uma vantagem importante dos genéricos vem da maneira como ele funciona bem com os novos recursos do Java 5. Aqui está um exemplo de como jogar números inteiros em a Sete calcular seu total:
Set<Integer> set = new HashSet<Integer>();
set.add(10);
set.add(42);
int total = 0;
for (int i : set) {
total += i;
}
Nesse trecho de código, há três novos recursos Java 5 presentes:
Primeiro, os genéricos e autoboxing de primitivos permitem as seguintes linhas:
set.add(10);
set.add(42);
O inteiro 10é autoboxed em um Integercom o valor de 10. (E o mesmo para 42). Então isso Integeré jogado no Setque é conhecido por conter Integers. Tentar lançar um Stringcausaria um erro de compilação.
Em seguida, o loop for for each leva todos os três:
for (int i : set) {
total += i;
}
Primeiro, os Setcontendo Integers são usados em um loop for-each. Cada elemento é declarado como um inte isso é permitido quando o Integeré desempacotado de volta para o primitivo int. E o fato de que esse desembalagem ocorre é conhecido porque genéricos foram usados para especificar que havia Integers retidos no Set.
Os genéricos podem ser a cola que reúne os novos recursos introduzidos no Java 5 e simplesmente tornam a codificação mais simples e segura. E na maioria das vezes os IDEs são inteligentes o suficiente para ajudá-lo com boas sugestões, então geralmente, não será muito mais difícil digitar.
E, francamente, como pode ser visto no Setexemplo, acho que utilizar os recursos do Java 5 pode tornar o código mais conciso e robusto.
Editar - Um exemplo sem genéricos
A seguir está uma ilustração do Setexemplo acima sem o uso de genéricos. É possível, mas não é exatamente agradável:
Set set = new HashSet();
set.add(10);
set.add(42);
int total = 0;
for (Object o : set) {
total += (Integer)o;
}
(Observação: o código acima irá gerar um aviso de conversão não verificada em tempo de compilação.)
Ao usar coleções não genéricas, os tipos inseridos na coleção são objetos do tipo Object. Portanto, neste exemplo, a Objecté o que está sendo addinserido no conjunto.
set.add(10);
set.add(42);
Nas linhas acima, o autoboxing está em jogo - o intvalor primitivo 10e 42está sendo autoboxing em Integerobjetos, que estão sendo adicionados ao Set. No entanto, lembre-se de que os Integerobjetos estão sendo tratados como Objects, pois não há informações de tipo para ajudar o compilador a saber que tipo ele Setdeve esperar.
for (Object o : set) {
Essa é a parte crucial. O motivo pelo qual o loop for-each funciona é porque o Setimplementa a Iterableinterface, que retorna uma Iteratorinformação do tipo with, se presente. ( Iterator<T>isto é.)
No entanto, uma vez que não existe informação de tipo, o Setretornará uma Iteratorque irá retornar os valores no Setcomo Objects, e é por isso que o elemento a ser recuperado na para-cada ciclo tem de ser do tipo Object.
Agora que o Objectfoi recuperado de Set, ele precisa ser convertido em um Integermanualmente para realizar a adição:
total += (Integer)o;
Aqui, um typecast é executado de um Objectpara um Integer. Nesse caso, sabemos que isso sempre funcionará, mas a conversão manual de tipos sempre me faz sentir que é um código frágil que pode ser danificado se uma pequena alteração for feita em outro local. (Eu sinto que cada typecast está ClassCastExceptionesperando para acontecer, mas estou divagando ...)
O Integeragora está desempacotado em um inte tem permissão para realizar a adição na intvariável total.
Espero poder ilustrar que os novos recursos do Java 5 podem ser usados com código não genérico, mas não é tão simples e direto quanto escrever código com genéricos. E, na minha opinião, para tirar o máximo proveito dos novos recursos do Java 5, deve-se olhar para os genéricos, se pelo menos permitirem verificações de tempo de compilação para evitar que as previsões de tipos inválidas gerem exceções em tempo de execução.