Diagrama de classes - problema de referência

Me parece que Cliente e Fornecedor deveriam estender de Pessoa Jurídica, não de Pessoa. E Funcionário deveria estender Pessoa Física, não Pessoa. Não sei dizer se é esse o problema que seus professores dizem ou se tem mais alguma coisa, mas esse seria um começo.

[]´s

Bem vindo ao forum Renato!

Eis aqui meu chute!

O “problema” relacionado a classe Pessoa é causado pelo uso da herança. Pessoa juridica, por exemplo, não tem (a principio) telefone celular; quando vc utiliza herança a estrutura da superclasse fica disponivel para a classe, logo, neste caso (pessoa juridica) herança pode não ser a melhor saida. O objeto pessoa juridica ficará com uma estrutura de dados para telefone celular sendo que ele não precisa deste atributo.

A saída indicada é o uso da agregação. Ao invés da classe Pessoa Fisica herdar a estrutura da classe Pessoa, ela (classe Pessoa Fisica) deverá agregar a classe Pessoa.

Inicialmente Pessoa Juridica, Pessoa Fisica, Cliente, Funcionario pode parecer um TIPO DE PESSOA nos levando a pensar que utilizar herança é a melhor opção. Mas na realidade Pessoa Fisica, Cliente, Funcionario e etc… são PAPEIS desempenhados pela pessoa dentro do domino por isso que herança não se encaixa muito bem como solução.

flws

Depois de acertar a questão da herança x agregação é necessário fazer uma revisão nos atributos / relacionamentos das classes. Me parece que dá para melhorar um pouco mais também.

flws

Aew galera, olha eu aqui novamente, mexi novamente no diagrama, adicionei uma classe papel pois uma pessoa pode ter mais de um no sistema e também adicionei uma classe de entrada e saída para fins de consulta/relatório, porém conversei com meu professor e ele disse que ao montar o banco, utilizar uma tabela para pessoa (pessoa, pessoa física e jurídica)[img], acho que fica meio incoerente, mas bom ele pediu pra pesquisar sobre problemas de herança múltipla, se algué puder ajudar aí agradeço.

Não rola fazer uma composição?

Aí colocaria cpf, cnpj e td que for relativo a pessoa na classe pessoa e o código ficaria assim:

public class Cliente {
private Pessoa pessoaa;
}

O mesmo seria pra Funcionario e Fornecedor
Poderia criar uma classe Endereco, nela vc colocaria logradouro, numero, complemento, bairro, cidade, estado, cep e pais, e relacionaria com Funcionario, Cliente e Fornecedor, ficando uma relação @OneToOne:

public class Cliente {
private Pessoa pessoa;
@OneToOne
private Endereco endereco;
}

Abraço!

asaudate:

Me parece que Cliente e Fornecedor deveriam estender de Pessoa Jurídica, não de Pessoa. E Funcionário deveria estender Pessoa Física, não Pessoa. Não sei dizer se é esse o problema que seus professores dizem ou se tem mais alguma coisa, mas esse seria um começo.

[]´s

Boa noite,

asaudate, tenho um modelo muito parecido, com o adotado pelo nosso amigo RenatoJP. A razão para essa estrutura, reside em que, tanto “Pessoa Fisica” quanto “Pessoa Juridica” podem ser, consumidor ou fornecedor.

Exemplos:

Como pessoa fisica, trabalho com manutenção e configuração, de servidor linux. Durante a execução, dessas tarefas, legalmente sou um fornecedor, de serviços. E a pessoa juridica, o consumidor, de minha mão de obra.

Uma pessoa juridica, me vende, cabo e conectores. Neste momento eu, como pessoa fisica, sou consumidor da loja. E a pessoa juridica, fornecedor, de componentes.

O que define, a condição de cliente ou fornecedor, está na posição ocupada, na relação comercial.

Nota: Perdõem a intromissão, meu proposito é somar, ao topico.

[]s

KaosBr:

asaudate:

Me parece que Cliente e Fornecedor deveriam estender de Pessoa Jurídica, não de Pessoa. E Funcionário deveria estender Pessoa Física, não Pessoa. Não sei dizer se é esse o problema que seus professores dizem ou se tem mais alguma coisa, mas esse seria um começo.

[]´s

Boa noite,

asaudate, tenho um modelo muito parecido, com o adotado pelo nosso amigo RenatoJP. A razão para essa estrutura, reside em que, tanto “Pessoa Fisica” quanto “Pessoa Juridica” podem ser, consumidor ou fornecedor.

Exemplos:

Como pessoa fisica, trabalho com manutenção e configuração, de servidor linux. Durante a execução, dessas tarefas, legalmente sou um fornecedor, de serviços. E a pessoa juridica, o consumidor, de minha mão de obra.

Uma pessoa juridica, me vende, cabo e conectores. Neste momento eu, como pessoa fisica, sou consumidor da loja. E a pessoa juridica, fornecedor, de componentes.

O que define, a condição de cliente ou fornecedor, está na posição ocupada, na relação comercial.

Nota: Perdõem a intromissão, meu proposito é somar, ao topico.

[]s

Oi, KaosBR! Interessante a sua colocação, ficou mais claro o modelo do amigo. No entanto, passo a concordar com o Guevara, que composição, nesse caso, seria mais elegante.

[]´s!

Boa tarde,

asaudate, concordo com a agregassão proposta, pelo Guevara, é bem vinda

RenatoJP , você tem, o atributo: ramoAtividade; Repetido em pessoa, fisica e juridica. Na sua solução, esse atributo não pode ser tranferido para, Pessoa tornando esta classe, mais coesa e removendo a duplicidade?

[]s

Eu modelaria da seguinte maneira:

public interface Pessoa {

   public String getNomeExibicao(); //Razão Social ou Nome
   public String getRegistroNacional(); //CNPJ ou CPF
}

public class PessoaJuridica implements Pessoa {

   private CNPJ cnpj;
   private String razaoSocial;
   ...

    @Override
    public String getNomeExibicao() {
	return razaoSocial;
    }
    
    @Override
    public String getRegistroNacional() {
       return cnpj.toString();
    } 
}

public class PessoaFisica implements Pessoa {

   private CPF cpf;
   private String nome;
   ...

    @Override
    public String getNomeExibicao() {
	return nome;
    }
    
    @Override
    public String getRegistroNacional() {
       return cpf.toString();
    } 

}

public class Cliente {

    private Pessoa tipoPessoa;

}

P.S: O problema é que a interface complica bastante para modelar para o banco de dados. (Ainda estou procurando outras alternativas).