Dúvida sobre Modelagens de Beans e Padrões

Programação Arquitetura
#41

A questão do artista em questao (!!!) é:

Códigos são legais par auma tabela referenciar a outra, para um objeto referenciar o outro, use uma referência.

Se seu Artista possui mais que um código como atributo, faz mais sentido você ter algo que se relaciona com o Artista (aponta pra ele) do que algo que sabe o código do artista e trabalha com ele (um dado privado).

#42

Em outras palavras é melhor você ter um :

class CD { String nome; String preco; Artista artista; }

Do que:

class CD{ String nome; String preco; Long idArtista;

É isso que você quis dizer Phillip?!?

#43

Exato

#44

Exato, Rafael… quanto menos partes do sistema sequer souberem que o Artista tem um ‘id’, esse treco artificial que vc colocou na classe por causa da persistencia :wink:

#45

E mais um conselho, não faça:

if(pearlJam.getCodigo()==creed.getCodigo()){
japoneix();
}

Pelo amor de Zahl, faça:


if(creed.equals(pearlJam){
 japoneix();
}

Não espalhe os dados das suas entidades musicais pelo sistema sem necessidade :wink:

#46

Phillip,
Mas para fazer isso:

if(creed.equals(pearlJam){ japoneix(); }
Eu teria de implementar um método equals() em todas as minhas classes. Não seria gerar um trabalho desnecessário?

#47

Se você quer criar boas abstrações, não.

Primeiro, você tem certeza que vai querer espalhar seus ifs por um milhão de lugares diferentes no código, podendo ao invés disso chamar um método?

Além do que, como o Carlos mencionou, o ID é algo artificial, geralmente precisamos criar dados assim para coisas como persistência ou comunicação entre sistemas, na maioria isso interessa a apenas uma ou duas classes numa única camada.

Se você amarrar todas as classes clientes da sua ao conceito de ID (pra começar já vai estar expondo um dado a mais!), você vai fazer com que todas dependam do atributo artificial que foi feito só para uma “gambiarra” qualquer.

Além do que, o papel de definir se um objeto é igual ao outro é relativo. De repente, o ID não é tão importante, eu não poderia ter duas bandas chamadas “Creed”, então meu equals deveria comparar os nomes também. Se eu fizer um && em todos os meus ifs espalhados por aí que comparam os códigos… putz, você vai aumentar o acoplamento enormemente por todo lugar.

Faça os clientes dependerem o quanto menos possível dos atributos das classes que disponibilizam um serviço, evite código repetido.

É claro que num sistema muito simples implementar equals pode ser um overhead, cabe a quem está programando analisar as opções, mas se você quer manter um acoplamento baixo, não dependa dos atrbiutos dos objetos :wink:

#48

Olá

Além do que o Phillip falou, saiba que fazer override de equals as vezes é ótimo, mas pode dar zebra. Lembre-se do capítulo 3 do livro Effective Java do Joshua Bloch que TODOS os programadores Java precisam ler ao menos uma vez:

Chapter 3, “Methods Common to All Objects”
:arrow: item 7: Obedeça ao contrato geral.
Regras básicas:

  • Não faça este override se:
  1. Cada instância da classe é única (exemplo: Thread)
  2. equals herdado de Object ou de uma superclasse é adequado
  3. A classe é privada (ou só visível dentro do pacote) e o equals nunca será chamado
    Caso faça o override:
  4. Use o operador == para verificar se o argumento é uma referência a este objeto
  5. Use o operador instanceof para verificar se o tipo está correto
  6. Coloque cast no argumento para o tipo correto
  7. Para cada campo “significante” da classe verifique se o tipo do campo é o mesmo do argumento
  8. Depois de pronto o método equals pergunte a si mesmo se ele é simétrico, transitivo e consistente.

:arrow: item 8: Sempre faça override de hashCode ao fazer override de equals

Mas por favor, sempre faça override do toString

[]s
Luca

#49