Hierarquia de Classes

Olá,

Depende da sua modelagem. O que essas classes tem em comum?

(nota: açguem vai dizer para pessoa ser superclasse de cliente, mas isso depende muito do contexto do que você esta modelando)

Phillip, pode citar algum caso em que Cliente não seria uma pessoa?

Primeiro, pdoe ser uma empresa
Continuando, pode ser uma aplicação cliente
E por ai vai…

Não dá pra dizer “Cliente é uma Pessoa”, “Usuario e uma Pessoa” sem saber o contexto.

Hun, creio que entendi.
Realmente não faz muito sentido ter sempre uma classe Pessoa se só existir um subtipo, por exemplo Cliente.

Ahhhh, mas qual sistemas so precisa ter um tipo de pessoa cadastrada? Tem sempre mais de dois tipos de Pessoa lidando no sistema.
Mas caso voce se depare com algo que não precise e bom pensar que amanha ele pode precisar!

Acho que o phillip quiz dizer o seguinte:
Usando o extends sempre vai dizer que cliente e um tipo de pessoa.
Já quando você instancia uma classe você pode estar usando apenas um metodo da classe Pessoa que por acaso retorna o valor de algum calculo; assim sua classe não tem nada a ver com pessoa so utiliza um metodo ja pronto.
Então de qualquer forma as classes se relacionam, mas a maneira mais certa vai depender realmente do contexto :).

Quando chegar em casa eu mostro a diferença no UML isso se eu lembrar :).

Não exatamente. Eu já trabalhei com muitos sistemas que so tem pessoa fisica, so pessoa juridica, tem ambos, tem ambos mas so um eh o cliente…

O que eu disse é: depende do contexto. O cliente eh uma pessoa em 99.9% das vezes, mas o que sera que ele esta chamando de pessoa? Sera que estamos falando a mesma lingua? Quais sao os requisitos? Cliente de que?

A resposta eh simples: nao afirme nada sem saber do que se trata, as vezes o obvio esta errado, depende do contexto

No contexto Usuário é uma Pessoa. então como é que ficaria ?

Mas e o Cliente?

A pergunta é: qual a relação entre pessoa e Cliente? Pessoa é um Cliente? Cliente é Pessoa? Existem outras classes que são Pessoas?

Sim Phillipe, Cliente é uma Pessoa porém nem toda Pessoa é um Cliente.

Sim, Usuário

Clientes e Usuarios tem que comportamento ou atributos em comum? Nao vale dizer “sao pessoas” queor saber na pratica, tem nome, tem cpf… o que?

Sim Phillip, Para simplificar ainda mais vou postar alguns atributos das classes Pessoa e Usuários.

Pessoas:

private String cpf;
private String nmPessoa;
private int sexo;
private String numIdent;
private String orgExped;
 // etc...

Usuarios:

private int tpUsuario;
 private String chave;
 private int Senha;
 // etc...

Atributos em Comum entre Usuarios e Pessoas:

private String cpf;
private String nmPessoa;
private String numIdent;
private String orgExped;
// e mais alguns

Ok, então pegue os atributos comuns, crie uma classe abstrata pessoa e faça cliente e usuario a extenderem.

Ah, procure usar nomes mais significativos e menos siglas nos seus identificadores

Phillip muito obrigado, e valeu pela dica !!!

\o/
Era isso que eu queria dizer!! So que nosso amigo P quiz complicar

Veja bem, no exemplo la de cima, ele deu um extends ai eu falei que independe dos seus requisitos, idioma blablabla. O extends ta forçando vc a dizer que cliente é uma pessoa mesmo se pessoa para o cara Pessoa for um abacate.
No segundo exemplo eu disse que a Cliente pode não ser Pessoa mais pode estar aproveitando algum metodo para receber algum valor de algum calculo ja pronto.

Ai vem a duvida do cara!!

“curio”:

Boa tarde javeiros,
estou com a seguinte dúvida possuo 2 classes que se relacionam são elas Pessoa, Cliente. O que eu gostaria de saber qual é a maneira correta de relacionar a classe Cliente com Pessoa.

Ai eu falei, de qualquer forma as classes estão se relacionando mas a maneira mais certa vai depender do contexto :).

O ponto de vista do amigo P focou apenas no extends numa tentativa de advinhar as regras de negocio do amigo!

Sem mais delongas desse assunto espero ter sido util