Já li algumas vezes, pessoas aconselhando a utilizando o Builder Pattern quando fosse necessário construir objetos mais complexos (3 ou mais parametros no construtor).
Comecei a modelagem de um novo projeto, e fui procurar casos para "experimentar "o Builder Pattern:
Um caso bem simples:
Endereco residenciaDoCliente = new Endereco()
.naRua(“Rua de Teste”)
.numero(“1000”)
.noBairro(“Bairro”)
.naCidadeDe(“Venâncio Aires”)
.noEstado(“RS”)
.comCepDe(“95800-000”);
Mas fiquei me perguntando se o Builder não teria o mesmo efeito de utilizar Setter’s:
Endereco residenciaDoCliente = new Endereco();
residenciaDoCliente.setNomeDaRua(“Rua de Teste”);
residenciaDoCliente.setNumeroDaResidencia(“100”);
residenciaDoCliente.setBairro(“Bairro”);
residenciaDoCliente.setCidade(“Venâncio Aires”);
residenciaDoCliente.setEstado(“RS”);
residenciaDoCliente.setCep( new CEP(“95800-000”) );
Ou se ainda seria melhor usar um Builder com Construtor com Tiny Types?
Endereco residenciaDoCliente = new Endereco().Builder( new Rua(“Rua de Teste”), new NumeroResidencia(“1309”), new Bairro(“Bairro”), new Cidade(“Venâncio Aires”), new Estado(“RS”), new CEP(“95800-000”) );
Já que ao utilizar o construtor ele garante a consistência do objeto, já que todos os parametros são de preenchimento obrigatório. Mas em relação ao Builder e Setter’s ambos permitem deixar lacunas vazias no objeto. (a diferença é que o builder permite objetos imutáveis?)
Gostaria da opinião de vocês sobre a criação de objetos?
Ao meu ver a melhor maneira é sempre a mais simples mas q ainda atende aos seus requisitos. Se usar Builder deixar o seu codigo menor e mais simples e ñ gerar nenhum problema use-o senão use o new. Eu particularmente sou adepto de passar td o necessário p/ o objeto no construtor e tentar manter o objeto como imutavel.
Sua pergunta é pertinente.
Sugiro que você leia o capítulo “Consider a builder when faced with many constructor
parameters”, do livro Effective Java (segunda edição).
Abraço
Vc pode recorar à um builder quando vc se depara com um construtor com muitos parametros mas nesse caso é mais provável q vc está atribuindo responsábilidades demais p/ a sua classe e q vc consiga um resultado melhor refatorando esse código e usando outras classes p/ encapsular alguns desses atributos. Listas longas de parametros é um bad smell analisado por Martin Fowler em seu livro sobre refatoring.
Na minha opinião, a primeira forma é muito estranha. Parece uma Interface Fluente, mas eu não vejo ganho em usar esse tipo de idioma para criar um objeto “plano” onde as “partes” não possuem uma ordem pre-determinada de construção. Para estruturas hierárquicas (vários objetos associados entre si em uma estrutura que possui regras que definem quem pode conter o que) pode ser uma opção interessante.
O pattern Builder se aplica quando você tem um objeto composto por várias partes e diferentes implementações dessas partes podem ser combinadas para formar um tipo específico de objeto composto.
Por exemplo:
Carro possui Motor e Pneus;
F1 extende Carro;
Para construir um F1 se usa MotorTurbo que extende Motor e PneusSlick que extende Pneus;
CarroPopular extende Carro;
Para construir um CarroPopular se usa Motor1.0 e PneusAro13;
BuilderCarro sabe que partes (abstratas) são necessárias para construir um Carro (abstrato);
F1Builder sabe as partes para construir um F1;
CarroPopularBuilder sabe as partes para construir um CarroPopular;
OrquestradorCarro sabe em que ordem se deve construir cada parte de um Carro;
Abraço,
Luiz