Abstração de objetos --> Cliente --> Empresa --> Vendedor --> Fornecedor --> Pessoa

Priorise a composição ao invés da herança!
Isso não é ideia minha não… é regra de padrões de projeto!

O que caracteriza uma pessoa física ou juridica?
As duas são pessoas, só que uma tem alguns atributos diferentes! Uma tem CPF outra CNPJ. Então podemos ter Pessoa->PessoaFisica e Pessoa->PessoaJuridica!
E o cliente? O cliente é uma pessoa? Não será que o Cliente é o Cliente e pronto? Ele não seria o Cliente e teria um cadastro de pessoa juridica ou um cadastro de pessoa física?
Então Poderiâmos ter Cliente.pessoa!

Para não ter que fazer uma verificação de tipos, a classe Pessoa poderia ser abstrata e ter um método abstrato que retorna-se uma enumaração TipoPessoa que seria implementado nas classes PessoaFisica e PessoaJuridica retornando respectivamente tipoPessoa.FISICA e tipoPessoa.JURIDICA ai é só fazer a conversão para o tipo apropriado quando necessário!

Não seria melhor

if(cliente.pessoa instanceof PessoaFisica) //O cliente é uma pessoa física else if(cliente.pessoa instanceof PessoaJuridica) //O cliente é uma empresa (Pessoa jurídica)

Não seria melhor

if(cliente.pessoa instanceof PessoaFisica) //O cliente é uma pessoa física else if(cliente.pessoa instanceof PessoaJuridica) //O cliente é uma empresa (Pessoa jurídica)

Na verdade esta prática não é recomendada.

Effective C++, Scott Meyers :

"Anytime you find yourself writing code of the form “if the object is of type T1, then do something, but if it’s of type T2, then do something else,” slap yourself.

Exemplo: http://www.javapractices.com/topic/TopicAction.do?Id=31

Valew eros.stein, não sabia disso :oops:

Mas comparar um atributo do objeto que diz de que tipo ele é e utilizar o instanceof não seria mais ou menos o mesmo algoritmo? Ou utilizando um enum para definir de qual o sub-tipo do objeto é mais recomendavel?

[edit]Só me referia a casos bem específicos em que fosse necessária a conversão para o sub-tipo, não sendo viável o uso do polimorfismo… Acho que o x@ndy também se referia a os mesmos casos [/edit]

drigo.angelo:

Valew eros.stein, não sabia disso :oops:

Mas comparar um atributo do objeto que diz de que tipo ele é e utilizar o instanceof não seria mais ou menos o mesmo algoritmo? Ou utilizando um enum para definir de qual o sub-tipo do objeto é mais recomendavel?

[edit]Só me referia a casos bem específicos em que fosse necessária a conversão para o sub-tipo, não sendo viável o uso do polimorfismo… Acho que o x@ndy também se referia a os mesmos casos [/edit]

O uso do instanceof não é proibido. Ele deve apenas ser usado com cautela. (beba com moderação =P)

Sempre que for possível usar polimorfismo, deve-se utilizá-lo! (ainda não vi uma fonte confiável que dissesse o contrário e mesmo se encontrasse seria uma contra inúmeras que dizem o contrário)

Bom, a primeira questão e mais importante é baseada nos padrões de projeto. A boa prática de programação OO diz que instanceof deve ser evitado.

Uma das “inúmeras” fontes que falei: <a href="http://www.artima.com/interfacedesign/PreferPoly.html">http://www.artima.com/interfacedesign/PreferPoly.html</a>

A segunda questão seria a performance, o custo de execução de um instanceof é caro. Hoje com PCs super rápidos e JVMs avançadas essa questão nem é tão discutida mais, mas já foi palco de grandes debates.

Modern JVM/JIC compilers have removed the performance hit of most of the traditionally “slow” operations, including instanceof, exception handling, reflection, etc.

As Donald Knuth wrote, “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” The performance of instanceof probably won’t be an issue, so don’t waste your time coming up with exotic workarounds until you’re sure that’s the problem.

Fonte: Steve - StackOverflow.com : http://stackoverflow.com/questions/103564/the-performance-impact-of-using-instanceof-in-java

É isso. Esse assunto já foi muito discutido anos atrás, se tiver interesse pesquise mais sobre o assunto.
Tenho certeza que vai encontrar muitas fontes interessantes.

Abraço.

Teve vários bons tópicos sobre este assunto aqui mesmo no guj.

Alguns tópicos aqui

A única coisa que eu teria cuidado com essa arquitetura do x@ndy é com a similaridade entre pj e pf.
Na prática há tantas diferenças, que fica quase inviável tratar como a mesma coisa sem ifs.
Por exemplo:
PF tem um nome e PJ nome fantasia e razão social.
Dependendo da hora e lugar para o PJ é interessar usar como nome um atributo ou outro.

Outro fator que deve levar em consideração é que uma Cliente pode ser também Fornecedor.

Eu considero que Cliente, Fornecedor são relações comerciais que existem entre a dona do sistema e um PF ou PJ.