Herança é utilizada em casos onde se tem uma generalização e especialização.
Não sei exatamente o problema que você está tratando, mas vale a pena se perguntar:
A classe ‘User’ é uma especialização de ‘PessoaFisica’? Ou,
Há algum dado ou comportamento em PessoaFisica que não é aproveitado e estendido pela classe User? Se sim, é porque User não deve ser uma especialização de PessoaFísica. Pensando no domínio do problema, especializações precisam de tudo o que a classe genérica oferece e provê mais comportamentos e/ou mais dados e/ou altera comportamento e dados da genérica.
A impressão que eu fico é que na maioria dos domínios, User e PessoaFisica são entidades independentes quando falamos de Herança. Vejo ‘User’ como a “coisa” que tem acesso ao sistema e, entre outras propriedades, possui um login e senha. ‘User’ pode ser não só uma pessoa física ou jurídica, mas também um outro software da companhia que precisa migrar ou transferir dados. Enfim, não vejo a classe User como uma especialização de pessoa física nem jurídica. Mas, é claro, tudo depende do problema que o seu software está tratando.
Normalmente, surge a necessidade de herança múltipla quando se mistura dois contextos diferentes em um mesmo modelo de classes. O problema de contextos diferentes é discutido no livro DDD (Domain Driven Design de Eric Evans). Veja só:
Você sugeriu que Funcionario é uma especialização de User. É necessário avaliar o que isso quer dizer… Se Funcionario é um User que tem acesso limitado há algumas funcionalidades do sistema, beleza, ele realmente tem cara de ser uma especialização de User.
Entretanto, você coloca que Funcionario também é uma especialização de PessoaFisica. O que isso quer dizer? Que Funcionario faz as mesmas coisas (ou tem os mesmos dados) que PessoaFisica? Beleza mais uma vez, ele tem cara de ser uma especialização também.
Mas os contextos podem ser diferentes:
Um ‘Funcionário’ do departamento de pessoal (DP) é um ‘User’ do sistema de folha de pagamento, mas, um ‘Funcionário’ da TI não o é. Mas, ambos os funcionários aparecem na folha de pagamento. O problema é que estamos falando de contextos diferentes: A primeira classe funcionário trata de autenticação no sistema e a segunda classe trata do negócio de folha de pagamento. Ambas as classes têm o mesmo nome, mas, não têm os mesmos objetivos.
É como se você criasse duas classes com nome ‘Funcionário’ em pacotes java diferentes. Uma classe trata das questões de usuário como, por exemplo, qual a primeira tela após o login irá aparecer para ele. E a segunda classe ‘Funcionário’ trata de questões de DP como, por exemplo, qual o seu salário e quantos dias foram trabalhados.
É necessário conhecer melhor o problema para saber se vale a pena ou não criar uma associação simples (não uma herança) entre User e outra classe do seu sistema.