Boas praticas de programação, sera?

Boa tarde pessoal, estou implementando alguns codigos e gostaria de saber se é uma boa pratica, ou se sugerem uma solução melhor.

Vou explicar o problema mostrando o codigo:
1º os beans.

package br.com.bean;

public class EnderecoBean {

	String rua;
	String bairro;
	
	public String getBairro() {
		return bairro;
	}
	public void setBairro(String bairro) {
		this.bairro = bairro;
	}
	public String getRua() {
		return rua;
	}
	public void setRua(String rua) {
		this.rua = rua;
	}
	
}
package br.com.bean;

public class PessoaBean {

	String nome;
	EnderecoBean endereco;
	
	public PessoaBean()
	{
	}

	public EnderecoBean getEndereco() {
		if(endereco == null)
		{
			endereco = new EnderecoBean();
		}
		return endereco;
	}

	public void setEndereco(EnderecoBean endereco) {
		this.endereco = endereco;
	}

	public String getNome() {
		return nome;
	}

	public void setNome(String nome) {
		this.nome = nome;
	}
}
package br.com.bussines;

import br.com.bean.PessoaBean;

public class CadastroPessoaBS {

	public void cadastrarPessoa()
	{
		PessoaBean pessoa = new PessoaBean();
		pessoa.setNome("Fabaum");
		pessoa.getEndereco().setBairro("Bosque da Saude");
		pessoa.getEndereco().setRua("Rua i");
	}
}

De inicio, sempre tive muitos problemas de ficar validando varios objetos para poder setar um valor, para evitar um NullPoiterException.

Uma solução, seria dar new em tudo, dentro do construtor, mas isso consome muita memoria, as vezes desnecessaria.

Outra solução que penso, seria dar um new somente quando precisar do mesmo.

Exemplo:

public EnderecoBean getEndereco() {
		if(endereco == null)
		{
			endereco = new EnderecoBean();
		}
		return endereco;
	}

Isso acabaria com a grande quantidade de if que colocaria no meu codigo, verificando se o Objeto é nullo.
Mas seria uma boa solução?

Outra questão:
O uso de metodos encadeados como esse:

pessoa.getEndereco().setBairro("Bosque da Saude");

é problematico de se usar? deixa o codigo acoplado?

Agradeço quem puder coloboarar…

Caro Amigo

Eu com minha pouca experiência com Java, acredito que o seu código não esta acoplado, não vi problemas

Abraços

Eu prefiro o seguinte estilo:

 import br.com.bean.PessoaBean;
 
 public class CadastroPessoaBS {
 
 	public void cadastrarPessoa()
 	{
 		PessoaBean pessoa = new PessoaBean("Fabaum", new Endereco ("Bosque da Saude", "Rua i"));
 	}
 }

e minimizar o uso de setters e getters - usar apenas quando você for fazer modificações. Também acho esquisito um “getter” criar alguma coisa.

[quote=thingol]Eu prefiro o seguinte estilo:

 import br.com.bean.PessoaBean;
 
 public class CadastroPessoaBS {
 
 	public void cadastrarPessoa()
 	{
 		PessoaBean pessoa = new PessoaBean("Fabaum", new Endereco ("Bosque da Saude", "Rua i"));
 	}
 }

Bem como disse a minha pouca experiência, agora sugiro que vc siga a instrução dos “cobras” como o thiagol rs

e minimizar o uso de setters e getters - usar apenas quando você for fazer modificações. Também acho esquisito um “getter” criar alguma coisa.
[/quote]

Eu concordo com o thingol, não gosto muito do estilo get().set()… como você irá saber que a Pessoa não tem endereço cadastrado ou se alguém que cadastrou esse endereço não preencheu os dados? Algo assim entende…

Porém não gosto de construtores que aceitam tudo como parâmetro, aliás, nem utilizo construtores com os campos pois caso eu queira mapear esse bean usando JPA fica mais fácil…

Prefiro algo do tipo:

Pessoa pessoa = new Pessoa();
// dados da pessoa
Endereco end = new Endereco();
end.setRua("");
end.setBairro("");
pessoa.setEndereco(end);

[quote=thingol]Eu prefiro o seguinte estilo:

 import br.com.bean.PessoaBean;
 
 public class CadastroPessoaBS {
 
 	public void cadastrarPessoa()
 	{
 		PessoaBean pessoa = new PessoaBean("Fabaum", new Endereco ("Bosque da Saude", "Rua i"));
 	}
 }

e minimizar o uso de setters e getters - usar apenas quando você for fazer modificações. Também acho esquisito um “getter” criar alguma coisa.
[/quote]

Thingol, e se a classe possui vários atributos, não ficaria estranho um construtor com vários parâmetros???

Os construtores são responsáveis por “abastecer” os objetos com os dados iniciais e prepara-los para a ação.

Quando você diz “vários” parâmetros está falando de quantos?

Pode ser o caso de delegar certas responsabilidades para outros objetos …

De fato, normalmente objetos que têm muitos atributos são um pouco suspeitos. Pode ser que, na verdade, eles sejam compostos de outros objetos (como o Cliente que tem um atributo Endereco), ou pior ainda, você tenha de criar um array (lembram-se daquela história de uma tabela que tinha 2000 campos ? Era porque a tal tabela não era nem um pouco normalizada).

E de qualquer maneira você precisa sempre ter um construtor sem parâmetros, para inicializar o objeto com todos os campos zerados. (Eu não incluí isso no meu exemplo).

A ideia de criar um objeto em um get veio pela seguinte razão:

por exemplo:
Quando eu precisar da informação do bairro de uma pessoa:

usaria dessa forma:

pessoa.getEndereco.getBairro();

mas dessa forma correi o risco de endereco estar nullo, e o meu sistema parar com um NullPointerException.

outra solução seria:

if(pessoa != null && pessoa.getEndereco != null)
{
    pessoa.getEndereco.getBairro();
}

mas desse jeito encho meu codigo de validações.

na verdade é um recurso tecnico(chamado gambiara) pra evitar exceção e validações em excesso

Por que tanta preocupação em testar se o endereço é nulo, mas ignorando o nome?

Eu optaria por criar métodos delegators na classe Pessoa (onde seriam feitos os testes da nulidade do endereço). Evitaria as violações à lei de Deméter, que implicam, sim, em maior acoplamento.

[quote=bzanchet]Por que tanta preocupação em testar se o endereço é nulo, mas ignorando o nome?

Eu optaria por criar métodos delegators na classe Pessoa (onde seriam feitos os testes da nulidade do endereço). Evitaria as violações à lei de Deméter, que implicam, sim, em maior acoplamento.[/quote]

no caso a validação seria somente feita no nome, validando somente o atributo final.

Tava preocupado com esse encadeamento loco.
Acho que vou fazer como o RaulCarlin sujeriu:

Pessoa pessoa = new Pessoa();
 // dados da pessoa
 Endereco end = new Endereco();
 end.setRua("");
 end.setBairro("");
 pessoa.setEndereco(end);

É simples, implementa-se muito mais codigo, mas não acopla como os metodos encadeados que eu iria usar:

pessoa.getEndereco().setBairro("Bosque da Saude");

Para a criação do objeto gosto de usar uma fábrica no próprio objeto. É só mais uma opção. :wink:

Tudo bem, é uma opção. Mas o teu raciocínio foi errado, essa abordagem não diminui o acoplamento.

O código em questão continua precisando “conhecer” as duas classes, Endereco e Pessoa.

Thingol e no caso de um repositório de dados e/ou componentes, seria má prática um construtor com vários argumentos ??

Por exemplo um repositório responsável por componentes e campos de uma rotina toda de estoque ou fiscal ??

PS. desculpas se fugi do assunto

Não entendi a sua pergunta. Mostra um exemplo!

Não existe problema em se ter um construtor com -muitos- parâmetros.
Mas se isso está acontecendo com frequência -pode- ser que esteja na hora de refatorar código e delegar coisas para outras coisas.

É que nem nos programas dos unix. Você -quase- sempre tem um programa pequeno, com poucos parâmetros que podem ser “colados” (bash script) para desempenharem uma tarefa maior e maior e maior até que o trem funciona. Né?
No mesmo contexto, existem ainda alguns programas que possuem vários parâmetros e estão componentizados .

Mudando um pouco de assunto! Concordo que é melhor delegar que usar um construtor cheio de parametros!

Mas o que tenho enfrentado muito vendo OO é o excesso de delegates em JAVA! Principalmente quando usando DAOs e tal! Sei que isso é melhor para o entendimento posterior do código, ou seja, por razões humanas mesmo!

Mas deve ter alguma maneira de estrurar em OO sem delegar tanto tarefas. Alguem mais concorda?

Exemplo :

Tenho um frame com várias abas, e cada aba possui seu próprio painel com campos e dados independentes, porém esses paineis estão todos em um frame e não se “conhecem”. Seria errado eu ter uma classe que vai conter referencias ( não objetos ) de todos os campos pra posteriormente utilizar campos de determinado painel em outro. Portanto meu repositório terá um construtor enorme, ( com certeza com mais de 40 parametros ).

Alguem tem alguma opinião ???

http://www.guj.com.br/posts/list/62818.java

Oi Omeganosferatu,

Cada aba é responsável por renderizar informações sobre determinado “conjunto de informações”, certo? Então teriamos uma aba, para a pessoa, outra para o endereço e assim por diante? Qual seria o problema, nesse caso, de passar o próprio objeto?

Minha sugestão é para que você siga a teoria do encapsulamento em OO. Essa boa prática, tornará seu código mais seguro e flexível. Ou seja, utilize os métodos getters e setters para interagir com o mundo fora de sua classe. Eu sugiro que você crie o objeto e chame os métodos. ex:

Endereco end = new Endereco();
end.setEndereco(“bla bla”);
end.setRua(“bla bla”);

endAux = end.getEndereco();

Internamente à classe, você trata (se não forem exceções de SQL), ou propaga as possíveis exceções para a classe que chama.

will be the force with you… 8)