Quebra de paradigma: Evite os construtores públicos. Como assim?
Autor: Ricardo Longa | Publicado: 2013-11-21T00:06:00-02:00

Você lembra quais as diferenças entre um JavaBean e um Pojo? Se sim, pule para o próximo parágrafo. Um&nbsp;JavaBean&nbsp;devem ter um construtor sem parâmetros, implementar java.io.Serializable, atributos privados e métodos assessores (seguindo a convenção, os get's e set's). E o Pojo? Qualquer outra classe Java diferente de uma classe&nbsp;JavaBean (qualquer coisa fique a vontade para discordar comentando no final da postagem).&nbsp;

Uma vez que aprendemos a escrever um&nbsp;JavaBean, todos os nossos problemas estão resolvidos. Criamos nossos atributos privados&nbsp;com seus respectivos set's e esquecemos o conceito de Encapsulamento. Bom, deixaremos esta discussão para uma outra oportunidade, vamos quebrar um paradigma por vez.

Para facilitar o entendimento, vamos começar analisando o&nbsp;JavaBean&nbsp;abaixo:









Como de costume, na maioria dos casos os desenvolvedores iniciam seus JavaBeans desta forma. Pois bem, pensando no âmbito da aplicação, como instanciaremos um objeto Pessoa? Fácil!&nbsp;







Até aqui está tudo certo, como tradicionalmente codificamos no nosso dia a dia.&nbsp;



Agora vamos mudar um pouco, apresento-lhes uma outra forma de implementar o mesmo&nbsp;JavaBean Pessoa:







Instanciaremos este novo&nbsp;JavaBean&nbsp;da seguinte forma.&nbsp;







Você consegue analisar tudo o que foi alterado e levantar as possíveis vantagens e desvantagens? Antes de prosseguir, pare por aqui durante poucos minutos e tente fazer uma auto-reflexão sobre estas alterações. Vou lhes ajudar em relação as alterações:&nbsp;



1° - Alteramos o modificador de acesso do construtor do&nbsp;JavaBean&nbsp;Pessoa para default;

2° - Criamos um método estático para a fabricação do nosso&nbsp;JavaBean.

Vantagens

Pensou bem? Encontrou alguma vantagem/desvantagem ou acha que apenas adicionamos complexidade ao código?

Here we go!

Primeira vantagem: Diferente dos construtores, os métodos têm nomes.&nbsp;

Os métodos estáticos utilizados para as fabricações do nosso&nbsp;JavaBean Pessoa pode ter o nome que você achar mais apropriado. Isto facilita quando disponibilizamos mais de um método de fabricação com diferentes parâmetros. Do contrário, teríamos diversos construtores sobrecarregados.&nbsp;

Segunda vantagem: Não se faz necessário criar um novo objeto sempre que chamados o método estático de fabricação.

Exatamente! Quem disse que precisamos sempre criar uma nova instância de Pessoa na memória? Diferente dos construtores, podemos nos beneficiar, por exemplo, do Design Pattern Flyweight&nbsp;que consiste em um pool de objetos Pessoa. Um exemplo:







Você sabe o que o método estático valueOf() da classe java.lang.Integer faz? Abaixo o código do método:







Se o valor passado como argumento estiver entre -128 e 127 será retornado o objeto Integer imutável existente no cache. Caso contrário, um novo objeto Integer será criado (a cada requisição). Performance!


Terceira vantagem: Podem retornar qualquer subtipo do seu tipo de retorno.

Muito interessante! Vamos supor que sua aplicação passe a ter sub-tipos de Pessoa (exemplo, PessoaFisica / PessoaJuridica). Será necessário encontrar todos os pontos da aplicação em que a instanciação está [Pessoa pessoa = new Pessoa()] e alterar para [Pessoa pessoa = new PessoaFisica()] ou [Pessoa pessoa= new PessoaJuridica()]. Pensa no trabalho e no perigo. Exemplo de como poderia ser:





Melhor ainda se, neste caso, Pessoa fosse uma interface. O cliente precisaria apenas conhecer os métodos definidos no contrato e não sofreria alteração alguma, continuando da seguinte forma (como vimos antes):





Desvantagens

Única desvantagem: Sem construtores públicos perdemos o poder da herança.

Sim e não! Classes que estão no mesmo pacote do JavaBean Pessoa&nbsp;podem herdar de Pessoa pois o construtor foi alterado para default. Porém, classe de outros pacotes não tem o mesmo direito, o que pode ser considerado uma vantagem pois encoraja o desenvolvedor a substituir a herança pela composição (será nosso próximo paradigma a ser quebrado?). &nbsp;&nbsp;

Um abraço e até a próxima!

Agradecimento: ao amigo Ednardo Martins pela dica da classe Integer.&nbsp;
Fonte: Effective Java (Joshua Bloch).