Olá, boa noite pra todos! Estou iniciando meus estudos em POO e gostaria de saber se alguém ai sabe a implementaçao de um programa que tenha uma classe pessoa, e as outras sub-classes que herdam dela (class pessoaFisica e pessoa Juridica) e mais 2 classes, cliente (irá herdar atributos da class pessoaFisica e pessoaJuridica) e class funcionario (herdando atributos somente da class pessoaFisica).
Alguém pode me ajudar nessa implementação? Tenho só conceitos teóricos… Por favor!!! :roll:
Olá,
seus conhecimentos teóricos já poderiam ser utilizados. Tente modelar as classes, use um diagrama de classes simples representando:
[list]Pessoa ( pai de todos )[/list]
[list]Pessoa Física ( estendendo de Pessoa )[/list]
[list]Pessoa Jurídica ( estendendo de Pessoa ) [/list]
[list]Cliente ( não pode ser Pessoa Física e Jurídica ao mesmo tempo, logo pode ser - herança, pessoa física ou jurídica) [/list]
[list]Funcionário ( estendendo de Pessoa Física ) [/list]
Identifique os atributos e comportamentos característicos de cada classe.
O que você pode quebrar um pouco mais a cabeça aí seria com a classe Cliente, porque ela pode ser dinâmica, ou seja, pode ser uma pessoa física ou pessoa jurídica, a nível de orientação a objeto confesso que fiquei na dúvida com essa situação, será que existe herança dinâmica ?
Mas na implementação, Cliente herdaria ao meu ver de Pessoa ( que seria uma classe abstrata ), e Cliente teria um tipoPessoa ( PF ou PJ ). E como Pessoa só existe na instância de um objeto pessoa física ou jurídica, você teria como saber todas as informações do Cliente.
Não sei se tem outra forma melhor, mais orientada a objetos pra esse problema, se alguém souber, posta … to curioso! Que eu tb não sei direito… 
Cliente é uma interface.
bzanchet, já que este é um fórum, vc poderia explicar melhor o porque de
Cliente ser uma interface.
Eu pensei nisso, só que dessa forma Pessoa Fìsica e Pesso Juridica deveriam implementar a interface Cliente. Só que como o problema foi proposto, Cliente deveria herdar de PessoaFisica ou PessoJuridica.
E se fizer Cliente uma interface ? Você não vai poder colocar comportamento específico nela, teria que delegar pra PessoaFisica e PessoaJuridica implementar. Só que nem toda PessoaFisica é cliente.
Alguém tem alguma sugestão ?
Cliente fisico, cliente juridico?
Parece meio feio mas, depende do que ira diferenciar essas duas classes, se tiver mais algum comportamento que diferencie ai sim pode-se justificar a distinção. Se não, relamente não sei o que poderia ser feito.
Olá galera,
estava lendo esse tópico e decidi dar uma opinião, que vai precisar ser amadurecida com a ajuda de vocês para ajudar ajudar a resolver esse problema.
Muitos sistemas incluem os conceitos de pessoa física, pessoa jurídica, cliente, funcionário, fornecedor, etc… e a implementação desses conceitos nunca é igual, ou padrão, por isso cada um aqui tem uma dúvida ou sugestão com relação a isso.
Em uma das vezes que precisei implementar isso, fiz uma classe abstrata Pessoa, e classes PessoaFísica e PessoaJurídica que estendiam essa classe, fornecendo implementações diferentes para métodos como validarDocumento, por exemplo. A indicação para o caso de uma Pessoa ser cliente, funcionário, ou fornecedor se dava apenas por atributos booleanos, já que uma pessoa poderia ser, ao memso tempo, um cliente e um funcionário. Isso também funcionava porque clientes, funcionários e fornecedores não tinham comportamentos específicos, além daqueles presentes em uma pessoa (seja qual fosse sua natureza).
Bem, depois de ler esse tópico, e imaginar que, neste caso em específico, cliente e funcionário poderiam ter comportamentos específicos, me veio à mente o padrão DECORATOR (GOF).
Para aqueles que conhecem o padrão pode ficar mais fácil imaginar porque pensei nele, e para aqueles que não conhecem vou colocar algumas informações sobre o mesmo:
Neste caso pensei que Cliente e Funcionário poderiam ser Decorators para Pessoa.
O que acham?
Como dissea idéia vai precisar ser amadurecida pela galera, e vai depender também se isso se aplica à necessidade exposta.
Vou esperar a manifestação de vocês para saber se vocês acham que tem a ver ou não, e para quem não conhece o padrão poder ler sobre o mesmo.
[]'s
Olha, não sei se a forma como resolvi é a melhor, talvez até tenha ficado complicada, mas tem funcionado:
Tenho pessoa como classe abstrata e PF e PJ como classes concretas até aí tranquilo.
E tenho q uma Pessoa possui um ou mais Roles, sendo Cliente, Funcionário, Fornecedor, etc, Roles. No meu caso além de indicar se era cliente ou fornecedor eu tinha de armazenar informações específicas, (limite de créditos, carteira de trabalho, de motorista, etc).
Para usar eu crio uma Pessoa (fisica ou jurídica) e atribuo roles a ela. No começo ficou estranho de manipular, mas resolveu bem o problema. talvez tenha complicado algo simples.
Qual é a razão de PessoaFisica e PessoaJuridica extenderem uma mesma classe Pessoa? Ora, vamos, a maior parte das semelhanças é forçada, pois não tem o mesmo significado em ambos (ex.: nome). Existem exceções, como endereço, mas acho que não são fortes o suficiente para justificar o uso de herança.
Minha implementaão seria: PessoaFisica e PessoaJuridica classes concretas, Cliente uma interface implementada por ambas. Funcionario, claro, uma classe concreta extendendo PessoaFisica. Simples assim.
Se alguma semelhança entre pessoa física e jurídica precisar ser explorada… algo como “precisa ter endereço”… usamos polimorfismo, oras. Interface ‘Enderecavel’ e implementada por ambas.
---- editado ----
Pode o usuário que avaliou minhas mensagens ao menos postar uma resposta explicando o por quê?
E se o funcionário tbm puder ser pessoa Juridica? Ou ainda eu tiver um fornecedor que seje pessoa fisica ou juridica?
GoF: “evite herança, prefira composição”
Creio que o caminho talvez seja mais pela composição do que pela herança, nesse caso. Se Cliente tivesse uma Pessoa, vc poderia atribuir PessoaFísica, PessoaJuridíca ou qualquer outra Pessoa que você pudesse vir a criar, sem que Cliente precise saber especificamente que tipo de Pessoa ele é.
Por outro lado, dessa maneira poderia se criar um problema no momento de referenciar os métodos ou atributos específicos de objeto PessoaFísica ou PessoaJurídica, sendo necessário efetuar casts de acordo com o tipo de Pessoa que existir em Cliente.
Tanto Funcionário quanto Fornecedor poderiam seguir a mesma linha.
Olá a todos
Vamos por partes:
Toda PessoaFisica é uma Pessoa
Toda PessoaJuridica é uma Pessoa
Uma Pessoa não é uma PessoaJuridica ou PessoaFisica
Todo Cliente é uma Pessoa
Todo Cliente é uma PessoaFisica ou uma Pessoa Juridica
Todo Fornecedor é uma Pessoa
Todo Fornecedor é uma PessoaFisica ou PessoaJuridica
Uma PessoaJuridica pode ou nao ser um Cliente
Uma PessoaFisica pode ou nao ser um Cliente
Uma PessoaJuridica pode ou nao ser um Fornecedor
Uma PessoaFisica pode ou nao ser um Fornecedor
Baseado nestes dados fiz o seguinte
Criei uma interface IPessoa com os metodos exclusivos da pessoa (ex setNome)
Criei uma interface IPessoaJuridica que herda da interface IPessoa com os métodos exclusivos da PessoaJuridica (ex setCNPJ)
O mesmo com IPessoaFisica
Criei uma interface ICliente com os metodos do exclusivos de um cliente (ex setLimiteCredito)
Criei uma interface IFornecedor com os metodos exclusivos de um fornecedor (ex setContato)
Criei 4 interfaces :
IPessoaFisicaCliente extends IPessoaFisica,ICliente
IPessoaFisicaFornecedor extends IPessoaFisica,IFornecedor
IPessoaJuridicaCliente extends IPessoaJuridica,ICliente
IPessoaJuridicaFornecedor extends IPessoaJuridica,IFornecedor
Crei uma classe PessoaGeral que implementa as 4 interfaces anteriores
assim posso usar:
IPessoa p = new PessoaGeral(); //terei apenas os metodos do pessoa
IPessoaFisica p = new PessoaGeral(); //terei apenas os metodos do pessoa e Fisica
IPessoaJuridica p = new PessoaGeral(); //terei apenas os metodos do pessoa e Juridica
IPessoaFisicaCliente p = new PessoaGeral(); //terei os metodos do pessoa, do pessoafisica e do cliente
IPessoaFisicaFornecedor p = new PessoaGeral(); //terei os metodos do pessoa, do pessoafisica e do fornecedor
IPessoajuridicaCliente p = new PessoaGeral(); //terei os metodos do pessoa, do pessoajuridica e do cliente
IPessoajuridicaFornecedor p = new PessoaGeral(); //terei os metodos do pessoa, do pessoajuridica e do Fornecedor.
Assim posso implementar apenas um codigo em PessoaGeral e o codigo serve para todas as pessoas definidas.
Quanto a composição não vejo como uma pessoafisica, juridica, cliente ou fornecedor pode compor uma pessoa, acho que uma pessoa é uma pessoa juridica e assim seria herança mesmo. Um cliente é uma pessoa ou tem uma pessoa, ou uma pessoa é um cliente ou tem um cliente??
Até agora, apesar de ser um codigo esquisito, dentro da poo acho o de modelagem mais correta.
Ainda tem um erro que eu poderia colocar assim:
ICliente p = new Pessoa(); // Isso não seria correto porque para ser um cliente ele teria que ser pessoa fisica ou pessoa juridica e por consequencia uma pessoa.
Gostaria que verificassem a modelagem com carinho para me ajudar a encontrar falhas e manter dentro dos paradigmas da poo como ter reutilização de código. Neste caso tentei isso, o mesmo método setCpf serve para PessoaFisica, PessoaFisicaCliente, PessoaFisicaFornecedor, o método setNome serve para todos, o metodo setLimiteCredito serve para PessoaFisicaCliente e PessoaJuridicaFornecedor.
Aguardo comentarios
Prezadas(os) amigas(os)…
Eu imaginei mais ou menos pra começar dessa forma:
import java.sql.Date;
public class Account
{
private int id;
private String userName;
private String pwd;
private String name;
private Date registration;
public Account(String userName, String pwd)
{
this.setUserName(userName);
this.setPwd(pwd);
}
public int getId()
{
return id;
}
public void setId(int id)
{
this.id = id;
}
public String getName()
{
return userName;
}
public String getPwd()
{
return pwd;
}
public String getUserName()
{
return userName;
}
public void setName(String name)
{
this.name = name;
}
public void setPwd(String pwd)
{
this.pwd = pwd;
}
public void setUserName(String userName)
{
this.userName = userName;
}
public Date getRegistration()
{
return registration;
}
void setRegistration(Date registration)
{
this.setRegistration(registration);
}
public void printAccount()
{
System.out.println(this.getName());
}
}public class CompanyAccount extends Account
{
private String cnpj;
public CompanyAccount(String userName, String pwd, String cnpj)
{
super(userName, pwd);
this.setCnpj(cnpj);
}
public String getCnpj()
{
return cnpj;
}
public void setCnpj(String cnpj)
{
this.cnpj = cnpj;
}
}
public class PersonAccount extends Account
{
private String rg;
public PersonAccount(String userName, String pwd, String rg)
{
super(userName, pwd);
this.setRg(rg);
}
public String getRg()
{
return rg;
}
public void setRg(String rg)
{
this.rg = rg;
}
}A classe cliente pode extesnds de PEssoa
[quote=andgonca]GoF: “evite herança, prefira composição”
Creio que o caminho talvez seja mais pela composição do que pela herança, nesse caso. Se Cliente tivesse uma Pessoa, vc poderia atribuir PessoaFísica, PessoaJuridíca ou qualquer outra Pessoa que você pudesse vir a criar, sem que Cliente precise saber especificamente que tipo de Pessoa ele é.
[/quote]
Perfeito.
E Pessoa poderia ser uma interface. Morte a heranca!
Que cruel Paulo…
Paulo, o exterminador?!
Bom… vi que a discussão é um pouco antiga mas estou com as mesmas dúvidas sobre como implementar isto…
Cara… eu penso igual você…portanto não tenho conhecimento de como fazer a implementação propriamente dita… quais seriam os atributos e métodos da sua interface Cliente?! pode me ajudar?! valeu!