arthurminarini:
...Eu uso o net beans 6.5 e quanto termino de criar os atributos pesso a ele para gerar automaticamente os geteres e seteres
Dont do that... analise com calma cada coisa, nem tudo é passivel de set's, vc pode mandar gerar todos os getters, mas os sets vc deve tomar muito cuidado... por exemplo, campo auto_incremento de banco de dados não podem ter métodos sets, eles são alterados apenas pelo hibernate no momento da persistencia...
Listas/Coleções não devem ter "set"s não há sentido em utilizar um set em uma list, e ate mesmo o "get" pode, as vezes ser evitado, escondendo a lista modificavel real, e liberando apenas um copia da lista... por exemplo
Acoplamento alto (não recomendado), perdendo o controle de seus dados
public class ProdutoGrupo {
//..outros atributos
private List<Produto> produtos;
public List<Produto> getProdutos() {
return produtos; //<==deve se ter cautela com isso
}
public void setProdutos(List<Produto> produtos) {this.produto = produto;} //<== não há razões para isso
}
usando a classe acima com acoplamento alto
GrupoProduto grupoA = getGrupoA(); //abstrai como o grupo A é retornado;
Produto produtos = new List<Produto>();
produtos.add(new Produto());
produtos.add(null);
grupoA.setProdutos(produtos); //percebe o descontrole deste método ??
//vc apaga todos os itens q estava la, e ainda manda lista q podem conter itens, que vc não controu na hora q foram adcionados...
//... agora outro contexto
grupoA.getProdutos().add(null); //percebe que posso adcionar qualquer coisa ? q não há controle ?
neste exemplo acima, a integridade da coleção de produtos do GrupoA é de responsibilidade de quem usa a classe, o que é uma abordagem totalmente errada, o correto é que a propria classe GrupoProdutos mantenha a integridade dos seus dados 100% do tempo, e não permita invasões e alterações sem as devidas autorização previsa
Acoplamento baixo (recomendado), retomando o controle de seus dados
public class ProdutoGrupo {
//..outros atributos
private List<Produto> produtos;
/**
* Retorna uma lista <b><u>NÃO</b></u> modificável de produtos deste grupo
* esta lista é apenas para consulta
* @return lista não modificavel de produtos.
*/
public List<Produto> getProdutos() {
return Collections.unmodifierList(produtos);
}
/**
* método interno, usado para modificar a lista de produtos
*/
private List<Produto> getModifierProdutos() {
return produtos;
}
public boolean add(Produto produto) {
//agora vc tem controle, pode checar o produto antes de adcionar
//se o produto não for valido pode lançar exceções
if (produto == null) throw new NullPointerException();
if (!testaProdutoDeFormaComplexa(produto)) throw new ComplexaException();
//e so quando o produto é conforme
return getModifierProdutos().add(produto);
}
public boolean remove(Produto produto {
//se um dia vc kizer, pode avisar a agleum q um produto vai ser removido
//agora vc pode tomar acçoes quando um produto esta para ser removido
//e so então
return getModifierProdutos().remove(produto);
}
public boolean remove(Class<?> clazz, index) {
if (clazz.equals(Produto.class))
return getModifierProdutos().remove(index);
else if( clazz.equals(OutraLista.class))
return getModifierOutraLista().remove(index);
else
throw new IllegalArgumentException("Não existe uma lista de " + clazz.getSimpleNome());
}
//vc pode incluir outros método como contains, apena para facilitar, pois um contains pode ser realizar atravez de getProdutos().contains()
//removido public void setProdutos(List<Produto> produtos) {this.produto = produto;}
}
A integridade da classe volta para dentro de GrupoProduto e agora esta classe pode garantir 100% a integridade de seus dados, e qualquer pessoa pode tentar violar, os seus dados e mandar dados incoerente, porem a classe tem todos os mecanismos para se defender disto
percebe a segurança q te da essa segunda abordagem ?? percebe que vc desacoplou sua classe da Coleção ??
percebe que outras classes agora não precisam ficar pisando em ovos na hora de usar as listas de GrupoProduto, com medo de simplismente estragar o relacionamento enviado dados incosistente ??
percebe que agora vc controla de verdade a consistencias dos dados de sua classe? e deixa ela menos exposta ao que tem fora dela ?
agora ninguem mais vai poder violar sua classe, pelomenos não sem o seu controle, não fora do seu dominio, não longe dos seus olhos! se um dia vc precisar mudar algo, sua classe vai estar bem protegida, e vc consiguirar modificar...
arthurminarini:
e manda tbm ele gerar o equas e hash code, ele pede para escolher qual compo fazer o equas e hash code eu sempre marco o compo que é a chave primaria. Estou correto? posso usar deste jeito que eu falei? ele gera certo? posso confiar no que ele gerou?
vc pode confiar sim, ele gera direito na medida do possivel... POREM!! POREM!!!
muita HORA NESSA CALMA! ... o ID nem sempre é bom... id é algo alterável facilmente... e o ID não identifica um objeto único, o ID identifica um REGIDTRO na tabela único... as vezes esses dois coincidem, mas nem sempre coincide...
o ideal é vc procurar o que é unico na classe... o ID quando é auto_incremento, é algo muito mutavel, pois antes de persistir é nulo, depois de persistir não é mais... c vc usalos, vai fazer as coleções HASH falhar, pois elas usam hashCode, e como ele altera depois de persitir... PUFF muda tudo apos um cascade persist de suas classes....
busque propriedades únicas da classe
por exemplo....
Pessoa ? cpf
Carro ? placa
Empresa ? cnpj
Endereço ? cep
Grupo ? descricao
enfim vc tem q bolar uma forma q fique único... se for usar ID, acoselho não usar hashList, se não depois q persistir, não vai conseguir encontrar nada nas suas coleções, a não ser q de um refresh na lsita
