Classes com associações em UML

Um dos princípios que regem a orientação a objetos é que as classes possuam características e tenham comportamentos que sejam inerentes a elas e traduzam o que elas representam.

Na sua classe Pessoa você colocou atributos como bairro, cep, cidade e estado que não são características de uma pessoa mas sim do endereço associado a ela. Ainda, pelo que entendi, o que você usou como atributo nomeado endereço, seria o logradouro+número. Estes, junto aos outros atributos anteriormente citados estão associados ao conjunto que caracteriza o endereço de uma pessoa. Seria a mesma linha de raciocínio que você utilizou para criar uma classe Contato com os atributos inerentes à ela.

Aconselho que coloque endereço como sendo uma classe e traga todos os dados referentes a endereço para serem atributos dessa nova classe Endereco. Faça então uma relação entre Pessoa e Endereco assim como você fez com Contato.

Fazendo essas alterações acredito que seu modelo traduzirá num código extensível de maneira mais correta e permitirá o reuso de forma mais eficiente.

Pegando algumas das informações dos comentários, ficou um pouco mais claro as necessidades da sua modelagem.

Eu entendo que seria interessante existir estas classes:

• PessoaFisica
• PessoaJuridica
• Endereco
• Pessoa
• Empresa
• Contato

Com algumas observações que me orientaram na correção da sua modelagem:

• Toda empresa, regularmente constituída, é uma pessoa jurídica, mas nem toda pessoa jurídica é uma empresa.
• Pessoa Física pode ter uma Empresa, mas uma Pessoa Física não pode ser uma empresa.

Sendo assim

1. Empresa herda de PessoaJuridica.
2. Pessoa tem uma Empresa. Remova a herança entre Empresa e PessoaFisica.
3. PessoaFisica e PessoaJuridica herdam de Pessoa.
4. Moveria as informações de endereço da Pessoa para uma classe Endereco. Pessoa tem uma lista de Endereco.
5. Pessoa tem uma lista de Contato, como está atualmente.

Outra coisa, usaria o construtor das classes para receber as informações delas, e não set. Avalie se precisa de todos os get existente. Se sim, pode mantê-los.

Sobre o campo tipo e o que explicou nos comentários, ele parece pertencer a uma classe Profissional que herda de PessoaFisica e, no caso de empresa, creio que a informação pertença ao Ramo (de atividade) da Empresa, na qual a Empresa tem um Ramo. Você pode usar este Ramo para PessoaFisica e abrir mão do Profissional, mas precisaria conhecer melhor o contexto para escolher. Mas deixo as duas opções.

Por fim, como disse nos comentários, creio que você pode optar por não usar herança alguma neste modelo e usar apenas composição. Mas na minha resposta eu preferi seguir o raciocínio de herança para não fugir muito do que já tinha. Lembre-se que não existe uma resposta certa e definitiva para este problema, pois as possíveis soluções são várias.

Sou da época da programação estruturada e agora estou retornando e tentando me adequar com a OOP. Fiz um diagrama abaixo, poderiam analisar se estou no caminho certo?

Só uma observação sobre este afirmação. Muito se escuta sobre OOP ser a evolução da programação estruturada, mas tudo depende do problema que irá resolver. É verdade que antigamente os códigos macarrônicos eram comuns e o OOP foi vendido como a salvação, mas é possível manter um código não-OOP bem organizado. Aliás, em anos de profissão, é o que mais vi até hoje.

De fato, aplicar OOP em uma aplicação é bem complicado e normalmente é recomendado para casos onde a regra de negócio é bem complicada, no qual comumente o DDD (Domain Driven Design) aparece para dar uma certa organização a estas classes todas que podem se repetir em diferentes domínios de uma mesma aplicação.

Como assim da época da programação estruturada? Mudou alguma coisa que eu não sei? Eu ainda faço programação estruturada. Talvez esteja um pouco confuso com relação aos paradigmas. Uma coisa não elimina a outra. Inclusive eu evitaria assumir novos paradigmas sem entender esse fundamento e entender porque está adotando um paradigma novo no seu projeto. Fazer porque está na moda não é um bom motivo.

Tinha algum problema e agora fazendo OOP o resolve? Se não, não tem porque mudar. Fazia errado no procedural? Vai fazer OO certo? É mais difícil fazer certo orientado a objeto.

Não sou dos mais fãs de getters/setters. E tem linguagem que isso faz pouco sentido, um dos motivos que já nem gosto de UML (e muita gente está vendo que era pra não gostar mesmo). E tem ideometodologia que prega que não deve usar. Mesmo OOP diz isso na sua forma mais pura, ainda que eu sempre ache um exagero.

O modelo parece estar acima da média. Mas é o que eu sempre digo, não sei qual é o problema, não posso dizer se é a solução certa.

Pessoa é abstrata? Deveria. O diagrama não mostra isso.

Ainda não está usando o construtor da maneira correta, parece não ter lido os links que passei na pergunta anterior.

Não sei se Contato deveria ser desta forma, mas estou especulando em um problema que não conheço. Pode ser que seja a solução exata. Será que endereço não deveria ter uma independência? Como é feita a relação entre as duas estruturas? Se for persistir como a relação é gerenciada?

Não sei o que é esse Empresa. O que está escrito na pergunta não me diz nada. Ou diz, que não faz sentido. Quem cria tem que justificar porque criou. Nunca crie algo que não saiba justificar muito bem. Mas depois dos comentários vi que não faz sentido mesmo, por duas razões: a pessoa física não pode ser empresa e o modelo fica torto assim podendo até não ter uma empresa, provavelmente não entendeu para que serve herança. É o que eu falei na pergunta anterior: aprenda primeiro como usar as ferramentas antes de usá-la.

A falta de entendimento do que está fazendo fará você cometer vários erros em sequência, e poderá cometer a vida toda se não criar uma base. Neste caso você precisa criar um objeto que seja uma pessoa, e já tem um tipo que define isso, é Pessoa, não tem que inventar mais nada. Mesmo ela sendo abstrata, e já falei que deveria ser, você pode criar objetos concretos, através de suas derivadas, mas guardar em uma variável do tipo Pessoa, e assim já tem o que precisa. O objeto será único para aquela entidade e obviamente seguirá exclusivamente um dos dois modelos atuais existentes: PessoaJuridica ou PessoaFisica.

Não sei se o tipo deveria ser string, mas pode ser, precisaria de um aprofundamento maior.

Será que não falta alguns setters? Talvez não, mas aí será que não falta um ou mais métodos que permitem alterar os dados de forma consistente?

Veja Tipo do campo CPF ou CNPJ no banco de dados VARCHAR ou INT?.

Nos comentários fala muito em empresas, empresa é só pessoa jurídica. Pode ser só uso do termo errado, mas como costumo dizer, se não souber sequer usar os nomes certos das cosias não saberá o que aquilo significa, qual o papel daquilo no modelo, aí o erro é iminente, procure por ontologia e taxinomia, pode ajudar modelar melhor se estudar mais profundamente.

Esta parte ainda é fácil, as pessoas erram no que vem depois. E estou curioso para ver esse depois, os comentários indicam boa coisa.