Fala galera…
estou com essa duvida faz um bom tempo…
o q vem a ser um JavaBean?? qdo posso (ou devo) usa-lo??
falow
Fala galera…
estou com essa duvida faz um bom tempo…
o q vem a ser um JavaBean?? qdo posso (ou devo) usa-lo??
falow
Basicamente, JavaBeans são componentes (classes Java) que aderem a uma certa padronização de código (por exemplo, ter métodos públicos chamados getNomeDaPropriedade e setNomeDaPropriedade) para ler e setar valores de variáveis da classe.
Com isso, fica fácil para outras classes que conhecem esta padronização utilizarem esse métodos.
Para ter uma idéia melhor, você pode ker a FAQ sobre JavaBeans da própria Sun: http://java.sun.com/products/javabeans/faq/faq.general.html
Vantagens outras dos JavaBeans são:
Vc pode utilizar um BeanBuilder para construir sua aplicação. Os JComponents são JavaBeans, e por isso o NetBeans, por exemplo, sabe quais propriedades mostrar para cada componente, e que tipo de ligação dá pra fazer entre os elementos.
JavaBeans normalmente têm suporte a “eventos de mudança de propriedade”: vc pode adicionar PropertyChangelisteners ao seu bean que escutam quando a propriedade “text” mudou, por exemplo. Existem também os VetoableChangeListeners, que podem vetar uma alteração (por exemplo, um número menor que zero ou um nome muito comprido) de acordo com o seu critério.
JavaBeans devem sempre ser seriáveis. Hoje em dia é possível usar um XMLEncoder para gravar o estado de um Bean, isso é muito legal.
Mas ao mesmo tempo que são vantagens, essas também são regras para criar um JavaBean novo. O padrão de getXXX e setXXX é ótimo e deve ser usado sempre. Mas outras coisas só são úteis quando vc quer um componente bem redondo que guarda estado e pode ser composto com outros (como é o caso dos componentes do Swing, que vc coloca um dentro do outro) de acordo com regras bem claras (por exemplo, layout: todo mundo tem a propriedade Size).
Mas eu diria que se vc vai mandar dados de um lado para outro (por streams), use um “JavaBean fraco”: objetos de uma classe que tem todo o padrão de getters e setters, Serializable, redondo e compacto (com poucas responsabilidades). Em vez de fazer uma chamada RMI assim
String getHomeAddress(String login, String password) throws RemoteException;
use:
UserAddress getHomeAddress(User u) throws RemoteException
Muitos beans com pouca responsabilidade provam que a união faz a força. Eu acho que a Sun divulga pouco e aproveita ainda menos os JavaBeans, pq eles são chatos de programar na mão.
aquelão!
cara, nao acho q seja chato programar um bean nao…
o Eclipse jah faz isso automaticamente…basta mandar ele criar os metodos getter e setter…
entao um javabean eh apenas uma classe q contem getXXX() e setXXX(y)???
essa classe nao precisa extender a outra classe especifica de bean ou algo parecido??
valew
Os JavaBeans mais simples são os que só guardam estado.
Além de getXXX e setXXX, os Beans devem ter suporte a notificação de mudança de propriedades, serialização, a princípio, um BeanInfo, que é opcional.
É meio obscuro porque os diálogos são assim:
Serializable não tem métodos porque eles estão imbutidos em Object. Mas quando vc implementa java.io.Serializable, vc está declarando que vc prestou atenção à persistência desses objetos. Se vc declara e não presta atenção, vc tá se arriscando a ter um programa que não funciona.
Mas isso é assunto pra outro tópico. Um JavaBean realmente não é nada demais. Mas um JavaBean mal escrito é sinônimo de dor de cabeça, por isso o pessoal faz poucos. E qualquer coisa bem feita dá trabalho pra fazer.
A especificação mesmo está aqui:
http://java.sun.com/products/javabeans/docs/index.html
Vai fundo!!!