Melhor forma de modelar/programar cliente, fornecedor e pessoa

This message was edited 1 time. Last update was at 07/09/2008 15:45:50

Alessandro Lazarotti wrote:Um é distinto do outro, não tem pq distinguir... eles são assim por natureza. É como distinguir pedra de fruta em um ancestral em comum, apenas para utilizar de atributos como "descrição, nomeCientifico, blabla".
Os dois não devem pertencer uma mesma hierarquia "Pessoa" (a jurídica e física), uma vez que Pessoa Jurídica não é necessariamente uma pessoa.
http://www.sebraesp.com.br/principal/abrindo%20seu%20neg%F3cio/orienta%E7%F5es/cria%E7%E3o%20de%20empresas/pessoasf%EDsicajur%EDdica.aspx
.( pessoa jurídica é a entidade abstrata com existência e responsabilidade jurídicas como, por exemplo, uma associação, empresa, companhia, legalmente autorizadas)

ja tinhamos discutido isso antes neste tópico.

Entendo perfeitamente que são distintos. Quando falei "caso seja necessário distinguir um ou outro", na verdade quis dizer "caso seja necessário no seu sistema utilizar cpf ou cnpj". Quis dizer apenas que, dependendo do problema, pode ou não ser necessário atribuir CPF ou CNPJ às entidades.
Mas aí é que tá, no caso dele que outra palavra poderíamos utilizar para designar alguém que pode ter vários papéis no sistema? Pra encontrar um modelo melhor, precisaria conversar com os clientes dele.
O post do GUJ que você linkou critica a utilização de uma entidade Pessoa em uma hierarquia Pessoa -> Pessoa Fìsica -> Pessoa Jurídica. Com isso aí eu concordo plenamente.

Alessandro Lazarotti wrote:Bom, não conheço mais detalhes da aplicação do hugleo, mas imagino que possa ser possível sim um vendedor ser um cliente em uma mesma transação. A empresa "Some CO" repassa produtos a vendedores autorizados, que dado a isso recebem descontos bem diferenciados além de detalhes tbm diferentes na nota. A entidade em questão esta em seu papel de cliente direto da fábrica mas tbm é vendedor, uma vez que esse é um dos critérios do negócio.

Não sei se entendi muito bem o problema, mas talvez na entidade Transação ( por assim dizer ) deveríamos ter dois atributos distintos: cliente e vendedor, por exemplo. Assim, bastaria ter dois objetos distintos da mesma "pessoa" ( ou como queira ), porém cada um com um papel diferente.

Não estou afirmando que qualquer modelagem descrita aqui é invalida, mas generalizar "Pessoas" por papéis ao meu ver é uma generalização difícil de se manter no sistema. Imagine a fluência do negócio no código, quando "ler" que pessoa.getNome() retornar "Petroquímica Danger LTDA".

Realmente, não tá muito legal. Mas não consigo pensar em uma generalização melhor sem conhecer o domínio do problema dele.

Thread.start() Membro desde: 16/02/2007 20:21:19 Mensagens: 29 Offline

A entidade Pessoa pode ser mudado para um nome melhor como DadosBasicos, pois não refleteria nenhum pessoa em si.
Tanto é que até pensei em colocar esses atributos como uma agregação, mas essa classe teria métodos de pesquisa no banco de dados. Aqui teria que usar SQL (e não persistência).
Por isso Dados básicos teria métodos que inserisse dados, cliente teria métodos que inserisse dados. E algum método (Transacao) faria em join nisso dado commit.

Cliente é Cliente, Fornecedor é Fornecedor, Vendedor é Vendedor. Eles podem sim assumir eventualmente o mesmo pepel. Ex: Eu sou Um Vendedor e vou vender um produto pra mim mesmo.
O que temos também é a Entidade Usuário, responsável por fazer login no sistema, mas não necessarimaente é um Vendedor.

Pessoa Jurídica, e Física também deveram ser distinguidadas. Algumas funções somente ficarão disponíveis pra PJ por exemplo.

Esses dados em comuns incluíria CPJ e CNPJ que teria o valor NULL (no banco) dependendo do caso.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

tnaires wrote: O post do GUJ que você linkou critica a utilização de uma entidade Pessoa em uma hierarquia Pessoa -> Pessoa Fìsica -> Pessoa Jurídica

Linkei o topico Tarso, por causa daquele ultimo comentario sobre PF e PJ do post anterior.

Mas concordo que esta modelagem esta estranha e que o segredo deve estar mesmo em outros detalhes do domínio.

This message was edited 1 time. Last update was at 08/09/2008 20:23:04

hmm, acho melhor vc realmente repensar no rumo que a modelagem esta tomando hugleo.

Se a classe Pessoa você cogita mudar ela para outro nome como "DadosBasicos", contudo tbm gostaria de adicionar métodos de pesquisa no banco de dados, talvez muitos conceitos estejam emaranhados por aí.

Uma classe do tipo "DadosBasicos" não deveria ser responsável por acesso ao banco, é uma responsabilidade fora de sua fronteira. Eu imagino ela como uma classe anêmica que simplesmente serviria como composição para outras classes que possuem esses atributos em comum.

A questão de: "eu sou Um Vendedor e vou vender um produto pra mim mesmo." parece se enquadrar bem no que o tarso falou, eles não compartilham papéis simultaneos em uma mesma transação.

Notícias, artigos e o maior fórum brasileiro sobre Java