Caros, boa noite.
Alguém pode me dizer qual a vantagem de se usar reflexão. Ainda não entendi muito bem por que utilizar reflexão…
Obrigado!
Frameworks.
No caso do Framework chamado JPA, ele usa reflection para saber se determinada classe é ou não uma Entity.
Nesse caso, ele vasculha classes anotadas com @Entity por reflextion.
E assim e outras funções com @EJB, @JSF e demais.
Então Reflexão só é útil para construir FrameWorks?
não necessariamente, imagine algo assim: “chamar uma classe que a sua aplicação não sabe se existe e um método que também não é conhecido”…
eu tive que fazer uma aplicação onde agendava determinados processos em um sistema; eu guardava na base o nome das classes e o nome dos metodos e as invocava dinamicamente.
existem inúmeras possibilidades…
não necessariamente, imagine algo assim: “chamar uma classe que a sua aplicação não sabe se existe e um método que também não é conhecido”…
eu tive que fazer uma aplicação onde agendava determinados processos em um sistema; eu guardava na base o nome das classes e o nome dos metodos e as invocava dinamicamente.
existem inúmeras possibilidades…
[/quote]
Carlos, obrigado.
Mas por que eu chamaria uma classe que não sei se existe?
No seu exemplo… Não seria melhor chamar direto uma classe do que manter seus nomes numa base de dados?
[quote=thiago90ap]Então Reflexão só é útil para construir FrameWorks?[/quote]Não. É mais aconselhável utilizar em Frameworks, mas podem ser utilizadas em aplicações também.
Frameworks tem que se adaptarem a qualquer aplicação, por isso que o reflection vem a ser uma mão na roda. O Framework procurará por configurações específicas e pronto.
O problema da reflection é que é um código custoso da memória. Uma aplicação normal não precisa por que você tem acesso a todo o código. Um Framework adicionado em sua aplicação não sabe que o método chamado iniciaTudo() é o método para inciar os objetos da aplicação. Basta anota o método como @PostConstruct que diversos frameworks saberão o que esse método faz.
[quote=thiago90ap]
Carlos, obrigado.
Mas por que eu chamaria uma classe que não sei se existe?
No seu exemplo… Não seria melhor chamar direto uma classe do que manter seus nomes numa base de dados?[/quote]
se eu fizesse dessa maneira teria que fazer um DE-PARA, hardcode para cada processo, e para cada processo novo teria que alterar essa classe…
dessa maneira usando reflection posso manipular o funcionamento do sistema apenas com os dados cadastrados na base; eu tenho uma unica classe que instancia e chama os metodos dinamicamente…
[quote=Hebert Coelho]
O problema da reflection é que é um código custoso da memória. Uma aplicação normal não precisa por que você tem acesso a todo o código. Um Framework adicionado em sua aplicação não sabe que o método chamado iniciaTudo() é o método para inciar os objetos da aplicação. Basta anota o método como @PostConstruct que diversos frameworks saberão o que esse método faz. [/quote]
o custo de memoria realmete é complicado;
e geralmente quando se usa reflection é uma ocasião muito especifica, que merece sempre uma segunda analisada pois pode haver problemas na arquitetura da sua aplicação; já vi aplicações usando erroneamente reflection para coisas triviais.
Sobre custo de memoria e performance da api de Reflection: http://buzdin.blogspot.com.br/2011/01/is-java-reflection-really-slow.html
Um exemplo bem pratico seria se você quisesse copiar um bean para outro bean, digamos que seu bean tivesse inúmeros atributos, ficar invocando setando o get de um no set de outro para copiar de um para o outro as vezes fica muito trabalhoso, com reflexão você resolve isto fácil. Hoje em dia existe algumas apis que já fazem isto como a BeanUtils (que faz exatamente isso). Dependendo do caso se precisar fazer uma copia bem profunda é mais vantajoso
utilizar serialização.