hugleo wrote:Tenho os seguintes papeis: Cliente, Fornecedor, Vendedor

Essas classes tem em comum, o endereço, como rua, telefone, e-mail, etc (uns 20 atributos).

Esses dados poderiam estar em uma classe Pessoa?

Mas aqui eu tenho o caso de por exemplo um Vendedor também poder assumir o papel de Cliente.

Qual a melhor forma de modelar isso? Eu criaria a classe Pessoa referentes a dados pessoais?
Quais a relação de classes que eu faria a herença ou agregação?

Usaria polimorfismo? Também não seria o caso, pois Cliente, Fornecedor e Vendedor possuem alguns atributos e métodos específicos.

Além disso, Cliente e Fornecedor possui outro atributos em comum mas que não fa parte de Vendedor. Nesse caso (como é somente um atributo), acredito que seria melhor que ele fique em Cliente e Fornecedor.

Essa abordagem é necessária por que minha aplicação possui um método que é responsável importar dados em comum, ou seja: O usuário da aplicação cadastra um Cliente, mas se ele quiser pode recuperar os dados em comum (como endereço, tel, etc), para não ter que digitar tudo novamente para efetuar o cadastro de Vendedor ou Fornecedor.

hugleo wrote:André Fonseca, nesse caso eu não teria que cadastratar obrigatoriamente que cadastar uma Cliente, Fornecedor e Vendedor para que seja possível montar a SuperPessoa? Então se eu cadastrar um Cliente ele seria também um Vendedor, o que nem sempre é verdade.

hugleo wrote:# interface Pessoa { # String getType(); # }

Tá, você criou interface Pessoa, então como fica o caso de: "Uma interface não pode possuir atributos de instância"
?
Já que existem atributos comuns entre Cliente, Fornecedor, Vendedor.

Talvez fosse ideal criar uma classe agregada, onde teria um tipo de dados.

# class Cliente { # DadosBasicos basicos; # }

Alessandro Lazarotti wrote:Qualquer modelagem que tenha uma entidade "Pessoa", pra mim é duvidosa.
A modelagem tem que expressar seu domínio e uma entidade pessoa é maior generalização de uma entidade referente ao negócio que se pode ter... (aka apelação).

Se o seu fornecedor, por exemplo, é uma empresa e não um "ser-humano" (mesmo essa empresa tendo nome, email, telefone, etc) seu domínio começa a ficar estranho... e classe como "SuperPessoa" (a não ser que seja um super herói) ou outras como "PessoaContext" só mostram como sua modelagem esta se distanciando de um modelo mais like domain.

Se são dados cadastrais gerais que você quer utilizar para esses caras, use uma classe que os agrupe da melhor forma pra você. Ela pode se chamar DadosCadastrais, CadastroBasico ou qualquer coisa mais criativa e compor as classes Cliente, Vendedor ou Fornecedor. Se mudar um atributo de cadastro, mudou para todos os outros.

A idéia da interface para este caso, tbm não me parece interessante, não vejo pq manter um contrato de comportamentos para tipos diferentes como Fornecedor e Cliente. Cada classe tem seu comportamento e não pertencem a mesma hierarquia ou tipo. O fato é que um Vendedor "tbm" pode ser um Cliente. Eu prefereria compor o vendedor de um cliente, se caso ele tbm é um cliente. Um metodo como isCliente() pode ajudar a definir os comportamentos em seu vendedor. Uma outra apelativa, mais técnica do que teórica, é que vc vai encontrar sobre tudo algumas dificuldades em mapeamento com o banco (ORM) quando decide optar pelo polimorfismo baseado em interfaces.

tnaires wrote: Não vejo problema nenhum em ter uma classe Pessoa no domínio. Caso você precise um dia distinguir pessoa física de pessoa jurídica, basta usar Strategy de novo e adicionar mais um atributo na classe pessoa para comportar seu tipo.

tnaires wrote:Tudo bem, um vendedor pode assumir o papel de cliente. Mas ele pode ser os dois ao mesmo tempo?
Acredito que não, ele assumirá apenas um papel por transação.