Definir Classes e subclasses, melhor opcao!

Sendo bem sincero, eu não vejo a necessidade de relação “É UM” (herança) neste caso. Para mim, residente, funcionário e aluno são tipificações de utilizador. No caso, eu criaria um enum TipoUtilizador, definindo todos os possíveis utilizadores e pronto.
Mas, se queres fazer assim, usando herança, seguiria o primeiro caso.

Ok estou a ver. O que estou a ter dificuldade, é o facto de ao registarmos um Funcionario que desempenha apenas funcoes administrativas do sistema, ele herda os atributos de um utilizador. Sendo que um utlizador tem associado a ele 1 CartaoRFID.
E este funcionario pode nao ser um utilizador do sistema, apenas funçoes administrativas.

Mas acontece o seguinte. Cada utilizador tem 1menu diferente com 1conjunto de funcionalidades diferentes.
O Utilizador do tipo “Aluno” e “Funcionario”, que não é “Administrativo” têm e mesmo tipo de funcionalidades.

E temos a classe “Visitantes” que sao as pessoas que têm necessidade de utilizar o parque de estacionamento mas nao sao registados no sistema.

Estou a embarcar no mundo de analise de sistemas e programacao orientado a objeto e ainda sou 1noob

Obrigado pela resposta.

Quando a estrutura de herança entre classes apresenta inconsistência, significa que ela precisa ser revista.
Veja:

public class Animal {
    private String fala;
    private int numeroDePatas;
}

public class Carnivoro extends Animal {
    public void almoco() {
        System.out.println("Comendo carne");
    }
}

public class PlantaCarnivora extends Carnivoro {
    public void almoco() {
        System.out.println("Comendo carne");
    }
}

Veja as classes acima. Consegue identificar uma inconsistência? Se sim, entende o que eu disse a respeito da tua estrutura? Talvez seja necessário rever o que quer que utilizador possua como atributos e métodos e redistribuir o que é adequado para as subclasses, sem que isso afete as que irão estender dessa.

Yah, percebi. PlantaCarnivora herda tudo do Carnivoro. E ela nao “fala” nem tem “numeroDePatas”. Atributos que nao precisava herdar.
E foi por isso que resolvi separar as classes que fazem a gestao do utilizador, e o proprio utilizador. O caso 2.

Vou analisar o meu caso outra vez e ver como posso redistribuir os atributos e metodos.

Não tinha me atentado a isso. Se há funcionários que não são utilizadores, então não existe relação entre eles.

Pois é. Esta foi a razao de pensar no caso 2.
Até agora estava a pensar em utilizar o seguinte esquema.
A ideia é trabalhar com esses dados e implementar no mySQL.

classes.png1311×311 7.33 KB

Só para eu me situar, o que você está estudando, no momento?

programacao orientado a objecto e base de dados.

Então, me parece que utilizador faz as vezes de uma interface e deve ser implementada por aluno, funcionário e residente.

Nao consegui ver como encaixar a interface no “Utilizador”.
O que difere os utlizadores, é o seguinte:

• O residente pode enviar um convite para alguem o que permite o acesso ao estacionamento. (O acesso ao parque é atravez de uma cancela automatica. Quem conseguir autenticar a cancela abre automaticamente).
• O aluno e o funcionario têm as mesmas funcionalidades, de um utilizador comum.
• Para registar o aluno temos de ter o numero de aluno valido, e quanto ao funcionario temos de ter o codigo de funcionario valido. Sendo o numeroAluno e codigoFuncionario chaves primárias.

Cada Utilizador tem associado 1 CartaoRFID que lhe garante a entrada no parque. E a entrada no parque será associado a chapaMatricula do carro com que autenticou.

Estou a expor o problema da melhor forma?
Porque as duvidas estao no estrutura do programa e nao no codigo em si…
Comecei a codificar, e guardar os registos, utilizadores, os menus, guardar os dados no ficheiro etc etc, mas sempre que me encontro com o pessoal do meu grupo de trabalho mudamos alguma coisa e tenho que voltar a mudar o codigo… Entao resolvi parar de codificar o projecto e tentar chegar a um ponto onde faz sentido implementar tal soluçao.

Caso precise de expor melhor as ideias e problemas de manera a ser compreensivel tanto pelo pessoal que tenham as mesmas duvidas ou quem quer ajudar, da uma dica aí.