Po pessoal, sabe quando vc faz mas não tem certeza e falta de conhecimento em outras opções… vou usar um exemplo.
numa análise vc tem um Cliente e ele possui Endereço, akise eu optar por uma composição vai ficar:
public class Cliente{
Endereco endereco;
}
certo? pois se eu deletar um cliente logo vai-se o endereço
mas se eu optar por uma agregação? como fica? como que faria para distinguir a agregação e composição? seria na lógica? no banco? ou é uma opção de desenvolvimento?
no banco sempre(eu acho) vai ser no cliente uma FK que é a PK de endereco, existe algo que amarre essas condições num banco? ou essa questão agregação/composição é na lógica do programa?
Olá amigo, tudo bem?
Tenho uma dica pra voce: cliente não se exclui da base nem quando ele para de ser seu cliente e passa a consumir na concorrencia (ou morre)…
Esse é um princípio de desenvolvimento pois se algum dia voce precisar ver uma venda ou outro dado antigo (como endereço) e tiver somente o registro da venda mas esse registro for órfão (registro correspondente na tabela cliente apagado) voce não encontraria esse cliente.
Sem dizer que o banco de dados viraria um queijo suíço se permitisse essa deleção.
Outra coisa: código de ex-cliente não é reutilizável para um novo cliente, nunca! Até por motivos de localizar um cheque ou uma determinada compra. Se reutilizar o código, o novo cliente ficará responsável pelos dados do antigo (e aí vira um rolo até com implicações legais).
Atenciosamente,
Geraldo
Em relação a pergunta, não há distinção entre agregação e composição em termos de código, a menos que você utilize um mecanismo de persistência como JPA que indique explicitamente quando um objeto deve ser removido junto com seu contenedor. A relação normalmente fica explícita na etapa de análise ou projeto via UML.
Boa tarde a todos.
Aproveitando a dica do nosso amigo Geraldocanteli, voce pode criar um campo dentro da tabela, onde conterá os valores “Ativo” e “Inativo”, podendo até ser um campo booleano com o nome da coluna como “Ativo”, assim voce pode usar critérios em instruções SQL de trazer somente registros cujos clientes são ativos, e de ter o registro inativo a sua disposição a qualquer momento, bastando apenas mudar o critério de pesquisa no SQL.
Em caso do Cliente deixar de comprar em sua empresa, voce pode torná-lo Inativo, pois é exatamente esta técnica que a maioria dos Bancos usam, eles não encerram conta de clientes que deixam de movimentá-la por mais de 5 anos, a conta permanece lá até porque se o ex-cliente quiser se tornar cliente novamente ? Com certeza ele se sentirá prestigiado ao saber que a sua conta ainda permance lá.
Esta lógica não só serve para conceitos de TI, mas também para conceitos de marketing.
Nos conceitos de TI, o nosso amigo Geraldo, já explicitou os motivos, que aliás são bastante relevantes, jamais exclua clientes em qualquer hipótese, pois voce algum dia necessitará de pesquisar justo aquele registro que por ventura voce deletou.
Pessoal, muito obrigado… eu a um tempinho ouvi sobre isso, de não deletar de fato os registros, parece algo tão básico né?! mas sem pensar muito ou sem orientação muitos pouco vão conhecer, se conhecer vão faze-lo depois de muitos regstros deletados e relatórios inconsistentes…rs
então, a definição de agregação e composição fica na documentação e sem a documentação não se vê no código e menos ainda no banco?