O padrão Bean
O padrão Bean está relacionado à simplicidade do Java quando se trata de trabalhar com propriedades. Simplicidade, aqui, significa que o Java não oferece nenhuma sintaxe especial para trabalhar com propriedades. Em vez disso ele oferece uma convenção.
O padrão Bean é mais convenção que um padrão de codigo,mas sendo que ele é suportado por codigo ele se torna um padrão na prática.
O problema
O problema é que o Java não tem uma sintaxe especial para definir propriedades. Propriedades são atributos das classes cujo valor altera o comportamento da classe. Estes valores têm que ser modificados e acessados várias vezes em mum programa.
Porque queremos seguir o principio de separação de responsabilidade a primeira coisas a fazer é encapsular estes atributos e prover métodos modificadores e acessores para eles. Mas quais?
A convenção
Convenciona-se que todos os modificadores de propriedades têm seu nome começado com a palavra “set” seguindo pelo nome da propriedade. Os acessores terão seu nome começado por “get” seguido pelo nome da propriedade. Se a propriedade é puramente logica (boolean) o prefixo “is” é usado em vez.
Para completar a convenção deve existir um construtor publico sem argumentos. Isto significa que o bean é criado “vazio” e utilizando os métodos modificadores o seu valor é alterado.
Java Beans e POJO
Java Beans é o nome de uma tecnologia da Sun semelhante em espirito aos ActiveX da Microsoft, mas simplificados para a plataforma Java. Java Beans seguem o padrão Bean, mas adicionam mais funcionalidades.
A mais importante funcionalidade é possibilidade dos Java Beans gerarem eventos que podem ser respondidos por quaisquer outras classes de objetos. O mais importante : PropertyChangeEvent
Java Beans podem ser visuais ou não. Em particular as classes filhas de JComponent são Java Beans visuais conforme especificação do Swing (JFC). A possibilidade dos Java Beans lançarem eventos é particularmente util em um ambiente de interface gráfica onde é necessários responder e controlar a interação com o usuário.
POJO signfica Plain Old Java Object e se traduz literalemnte por “Simples, Velho Objecto Java” e que podemos traduzir de uam forma mais coloquial por “Objecto Java Puro e Simples”. Esta sigla serve para representar objetos que não têm relações de herança com API especiais, eles dependem apenas da API padrão do Java. Os POJO também aderem comument ao padrão Bean a ponto de podermos indntificá-los um com o outro. 1
Integração
Os Beans têm suporte especial de outras API e ferramentas. São suportados, em particular, pelo pacote java.beans da API padrão e pela JSTL API utilizada em criação de páginas JSP.
Beans e Anti-Patterns
Por causa do uso extensivo do padrão Bean em todos os objetos Java ele se tornou uma forma padronizada de codificar classes sem que o programador perca um tempo pensando se realmente a classe necessita ser um Bean. A maior parte das vezes precisa já que encapsular as propriedades é algo muito comum, contudo é facil errar ao classificar uma atributo como propriedade e é ai que mora o problema.
O uso impensando de modificadores (setters) e acessores (getters) para todos os atributos da classe tornam-a em um anti-Bean: uma classe que tem propriedades mas elas não são independentes umas das outras. Isto é notório quando uma certa propriedade é calculada pela classe, mas mesmo assim existe um modificador para ela. Cair no anti-Bean é uma passo fácil e por isso comum. Contudo, é melhor um anti-Bean que encapsulamento nenhum. Um Bean pode facilmente deixar de ser um Bean com alguma modificações, mas uma classe não encapsulada não se pode tornar encapsulada facilmente.
Licença
 |
Sérgio Taborda Este trabalho é licenciado sob a Licença Creative Commons Atribuição-Uso Não-Comercial-Não a obras derivadas 3.0 Genérica . |
Sérgio Taborda's Weblog 
Bem interessante, concordo que o uso exagerado de getters e setters atrapalha e acaba prejudicando muito a maneira que é exercído o código, mas neste caso um estudo e planejamento de classes sob a forma de negócio ao invés de fantoches ajuda um pouco a resolver este problema.
Creio que neste caso deve ser avaliado se realmente irá necessitar de tantos setters, muitas vezes nem precisamos de metade dos setters que usamos ainda mais quando estamos atribuindo valores a seus atributos, creio que um estudo mais a fundo no uso do proprierty mude radicalmente o conceito de trabalhar com esses atributos, se observar um componente nem sempre precisa manter todos os atributos privados, mas só deve se manter públicos os métodos que serão usados fora do componente, dentro do componente tudo vai depender da real necessidade do mesmo.
O que estou dizendo vai além de alguém querer fazer uma gambiarra em esconder a zona que ocorre dentro de um componente, está mais a pensar a respeito da arquitetura que trabalha o componente, na realidade esse conceito de desenvolvimento apesar de deixar o código mais limpo e a execução mais rápida também acaba sendo mais difícil de trabalhar, já que precisa de um designer de código antes de toda implementação.