Generics - Não consigo instanciar o tipo.

Ola para todos,

estou com um problema e não estou conseguindo resolver.

vejam só criei uma classe utilizando generics

public class Principal<E> extends JPanel implements InitializingBean {

porem essa mesma classe que eu passo como parametro no generics eu quero chamar uma outra classe com um objeto do tipo E instanciado

alguem sabe me dizer como eu faço isso??

eu ja fiz instanciando um Object() com cast em E

porem tenho meu objeto tem q ser do tipo E e nao java.lang.Object

se alguem puder me ajudar.

grato

andre

Você não consegue instanciar o tipo E se não tiver um objeto do tipo Class<E>.

Exemplo, please

Ah, eu achei q tivesse uma forma de invocar o new com generics, da mesma forma q se pode fazer em C#

Mas valeu o exemplo!!

This message was edited 1 time. Last update was at 10/04/2008 22:28:23

Esse é um dos motivos que me faz ter saudades das templates do C++...

A solução com newInstance() pode até funcionar, mas também deve disparar alguns "warnings" na sua cabeça.
Veja os problemas:
1. O código assume que existe um construtor padrão, e que ele é suficiente;
2. Se isso mudar, o código não dará erro de compilação, só de execução;
3. É certamente mais complexo do que um código não-genérico e reflexivo.

Então, considere com cuidado a possibilidade de não utilizar coisas desse tipo.

Resolvido !!!

valew pela ajuda.

This message was edited 1 time. Last update was at 11/04/2008 15:59:27

ViniGodoy wrote:Esse é um dos motivos que me faz ter saudades das templates do C++...

A solução com newInstance() pode até funcionar, mas também deve disparar alguns "warnings" na sua cabeça.
Veja os problemas:
1. O código assume que existe um construtor padrão, e que ele é suficiente;
2. Se isso mudar, o código não dará erro de compilação, só de execução;
3. É certamente mais complexo do que um código não-genérico e reflexivo.

Então, considere com cuidado a possibilidade de não utilizar coisas desse tipo.

Na realidade isso é um tipo de inversão de dependencia e não de genericos. A ideia é plugar a implementação
da classe através da instanciação dela dentro da classe que a contém. É o mesmo principio de E e = new E() que o tingol falou e que se usa muito ainda.
Só que se pensa "se eu passar um classe generica eu posso instancia-la genericamente" quando deveria pensar "eu quero injetar uma implementação de E" Para isso eu tenho que promover a injeção dessa instancia ou usar um ServiceLocator da vida. É ignorar DI que é errado e não newInstance() ou generics

Ou seja, meu exemplo seria melhor assim:

Ou seja, a classe PlanoSaude não deve criar ela mesma os funcionários ou diretores; ela deve receber instâncias dessas classes.

Sim, vc está certo.

Só ressaltei pq se o java suportasse uma construção como:
E e = new E();

Poderia fazer verificações em tempo de compilação, e testar se E realmente tem um construtor sem qualquer tipo de parâmetros. Coisa que o C# e o C++ fazem muito bem.

No caso da instanciação com reflection isso não ocorre... se vc fizer caca, o erro vai cair só durante a execução.

Depois que o Neal Gafter saiu da Sun (e ele deixou de ser vidraça para ser estilingue

) , ele sugeriu que essa parte de Generics também aceitasse "reification", ou seja, que o tipo E também estivesse disponível para a classe poder fazer algo como "E e = new E()" e outras coisas.

This message was edited 1 time. Last update was at 11/04/2008 16:42:41

thingol wrote:Depois que o Neal Gafter saiu da Sun (e ele deixou de ser vidraça para ser estilingue ) , ele sugeriu que essa parte de Generics também aceitasse "reification", ou seja, que o tipo E também estivesse disponível para a classe poder fazer algo como "E e = new E()" e outras coisas.

Isso é o tipo de gambiarra que o C faz e que fere o conceito OO profundamente.
Se E é uma interface como fica toda esta historia ? O new tem que saber que está chamando uma interface ?
Imaginem

com Funcionario sendo interface e

Como a linha 1 sabe do erro da linha 2 ?

É por essas e por outras que erasure é suficiente. Porque dar poder de mais é tornar Java em C++. Ou seja, na linguagem mais baseada em gambiarra que existe.

This message was edited 3 times. Last update was at 11/04/2008 17:34:50

sergiotaborda wrote:
Isso é o tipo de gambiarra que o C faz e que fere o conceito OO profundamente.

O C não faz, quem faz é o C++.

Na verdade, não é uma gambiarra. Pq o conceito de templates não foi feito com a intenção de ser compatível com OO. É um paradigma totalmente diferente, chamado Metaprogramação e que, realmente, em muitos casos é contraditório à OO. A comunidade C++ está ciente disso, como você pode ver neste artigo aqui). Essa, na verdade, é a grande característica que difere o C++ de outras linguagens (inclusive o C): a possibilidade de programação multi-paradigma. Além da metaprogramação, o C++ ainda inclui o paradigma estruturado, muito baseado no C.

Se você ver a programação genérica do C++ vai ver que ela tenta expandir as possibilidades de reuso, estendendo a linguagem C++ e praticamente eliminando a necessidade de tipagem. É justamente o oposto do conceito de generics, que torna a tipagem mais forte e permite que uma classe que, de outra forma seria aberta demais (como a antiga List) fique mais restrita (List<Classe> ou List<? extends Classe> ).

Tipagem forte é um dos pontos chaves da Orientação a Objetos: na OO, vc define classes, que nada mais são do que tipos fortes e essas classes devem interagir com um grupo restrito de outras classes, também de tipo forte. E o Java é uma linguagem que se orgulha de implementar com grande perfeição o conceito de OO. Por isso, ao meu ver, a implementação dos generics reforçando o conceito de tipos (e não como no C++) foi acertada. Mesmo que a solução final não seja tão poderosa.

Mas lógico... a interação entre dois paradigmas não é suave. O que é bom num lugar, pode ser radicalmente negativo em outro. E, embora você possa realmente aproveitar os pontos fortes de cada paradigma em diversas situações no C++, vai ter aquelas em que você terá que encarar filosofias inconsistentes. E estou falando de maneiras totalmente diferentes de pensar no problema, não só de mecanismos de programação.

Será que adicionar tanta complexidade vale a pena? Já vi muitas coisas interessantíssimas que são possíveis com a metaprogramação, que nem sequer passam nos sonhos dos programadores java... mas entre essas coisas, encontram-se erros obscuros também...

sergiotaborda wrote:Se E é uma interface como fica toda esta historia ? O new tem que saber que está chamando uma interface ?

O compilador teria a capacidade de saber no exato momento que você tentasse fazer:

O compilador então acharia dentro do código de classe algo como:

E geraria um erro de compilação.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3008 Offline

ViniGodoy wrote:

sergiotaborda wrote:Se E é uma interface como fica toda esta historia ? O new tem que saber que está chamando uma interface ?

O compilador teria a capacidade de saber no exato momento que você tentasse fazer:

Classe<Interface> x = new Classe<Interface>();

O compilador então acharia dentro do código de classe algo como:
Interface e = new Interface(); //Antes E e = new E();

E geraria um erro de compilação.

Sim, no C++ onde ha substuição sim (é gerado um novo codigo com E subtituido)
Eu estava falando em java em que não ha substituição/geração de codigo.

Pior, a classe pode ser abstrata e o uso de interface poderia ser feito noutra classe que nem sequer está no projeto. E aí ?

Notícias, artigos e o maior fórum brasileiro sobre Java