Comprehensive Entity Enrollment Modeling

I think the way to make it as generic as possible is to keep just Individual and Legal , so both are People but the best way to do this is to start drawing as you can see in the Class Diagram below (Using your classes as an example):

InthisimageyoucanseethataPersoncanbeanytypeofperson,andeachtypeofpersoncanbedefinedintheenumTypePerson,thiswayifinthefuturethereisaneedtoaddanewonetype,justaddthenewtypeinthisenum.

HOWIT'SINTHECODE

Thiscanbewritteninjavawith3classesand1enumerator.

publicenumTipoPessoa{CLIENTE,FUNCIONARIO,FORNECEDOR,CONTATO}

publicclassPessoa{privateTipoPessoatipoPessoa;privateStringnome;privateStringapelido;privateEnderecoendereco;privateDatedataAtualizacao;privateDatedataCadastro;privateStringemail;privateStringfone;}

publicclassPessoaFisicaextendsPessoa{privateStringrg;privateStringorgaoEmissor;privateStringcpf;//demaisatributos}

publicclassPessoaJuridicaextendsPessoa{privateStringnomeFantasia;privateStringrazaoSocial;//atualmentefoialteradoparanomeEmpresarialprivateStringcnpj;privatePessoaFisicacontato;}

HOWTOUSE

publicclassMain{publicstaticvoidmain(Stringargs[]){PessoaJuridicacliente=newPessoaJuridica();cliente.setTipoPessoa(TipoPessoa.CLIENTE);cliente.setNome("Exemplo Cliente");
            cliente.setCnpj("123123123123");

            PessoaJuridica fornecedor = new PessoaJuridica();
            fornecedor.setTipoPessoa(TipoPessoa.FORNECEDOR);
            fornecedor.setNome("Exemplo Fornecedor");
            fornecedor.setCnpj("123123123333312");

            PessoaFisica clientePessoaFisica = new PessoaFisica();
            clientePessoaFisica.setTipoPessoa(TipoPessoa.CLIENTE);
            clientePessoaFisica.setNome("Exemplo Cliente Pessoa Fisica");
            clientePessoaFisica.setCpf("12312312333");

            PessoaFisica funcionario = new PessoaFisica();
            funcionario.setTipoPessoa(TipoPessoa.FUNCIONARIO);
            funcionario.setNome("Exemplo Funcionario");

            List<Pessoa> pessoas = new LinkedList<Pessoa>();
            pessoas.add(cliente);
            pessoas.add(funcionario);
            pessoas.add(fornecedor);
            pessoas.add(clientePessoaFisica);

            for(Pessoa p: pessoas){
                System.out.println(p.getNome() + " - " + p.getTipoPessoa());
            }
        }
    }

EXIT

    Exemplo Cliente - CLIENTE
    Exemplo Funcionario - FUNCIONARIO
    Exemplo Fornecedor - FORNECEDOR
    Exemplo Cliente Pessoa Fisica - CLIENTE

Several forms are possible according to the need I do not know. It could be something like this:

public class Cliente {
    private String CNPJ;
    private String CPF;
    private String Comprador; //só exemplos
    private DateTime UltimaVenda;
}

The first fields must be used exclusively, so you can check which is in use by analyzing if the other is null. If you think this is not ideal, you need something more concrete to validate and avoid accidental changes, you can create a field that tells you whether the person is a physical or a legal person.

Obviously this is a simplification of the class, it would be interesting to have builders and methods that would help the good use of it. Unless it's pure DTO or something, which has to follow what the database establishes.

I will not even show the supplier, it's the same thing. It does not matter what the relationship type is.

It makes sense, but I do not guarantee that it will achieve all the necessary goals. It seems to be all right. Maybe it could be better.

The link with Pessoa is for a reference to the object, I do not like it that much. Makes sense, but may limit some scenarios. In database or other form of persistence, this does not work.

I liked that you did not use inheritance, I think the composition or the relationship is better in this case. Other people would have done "OOP". It would bring some advantages, but it would also have drawbacks. There are no perfect models, you have to choose which problems you want to deal with.

Some people would prefer to link objects in reverse. That is, Pessoa would have a bind information with PessoaFisica or PessoaJuridica . And each of these two would have fields to link with the type of relation that has with the entity being registered there in the object, that is, it would have a field to bind with Cliente , another with Fornecedor , and others as it arises the necessity. This would allow you to move with Pessoa by the application and access all information of a specific person. Obviously I would require change in the classes whenever I add a new type of relationship (actually it is possible to have an auxiliary class to handle this without requiring changes to the existing class).

In the current model the opposite is also valid, although more rare, after going from bottom to top a change in the types of person is that would force changes in Cliente , Fornecedor , etc. One day a PessoaEstrangeira may appear, which would force the addition of a field in the class up there.

It is possible to standardize the link information and have only one link field (in the example I used CNPJ E CPF ), solving the question quoted in the previous paragraph and the previous one when talking about adding types of relationships. But if this is done, it would become mandatory to have a field saying what kind of person.

I think to give flexibility the ideal is to have links on both sides, that is, if you have Pessoa , you access the data of PessoaFisica and Cliente (just to stay in an example) of that person. If you have an object Cliente , it gets the data of PessoaFisica and Pessoa related to it.

Any questions you might be interested in:

• What to do if client can be both PF and PJ?
• Can it be considered a bad modeling practice to store all people (customers, employees, suppliers) in a single table?
• Database should follow OO?
• Inheritance and Polymorphism
• How does constructor inheritance work in Java?
• Get and display data of an attribute of class type

And my answer here .

If I remember other details, I'll post them later.