Le persone sono solo persone.
Un istruttore può frequentare un corso e, quindi, essere uno studente. Un amministratore può anche istruire. Uno studente può prendere diverse classi e quindi avere diversi istruttori. Quindi, è meglio non confondere le nozioni dell'identità di una persona con il ruolo (i) che giocano e per adattarsi ai ruoli che giocano sono contestuali.
Molti sistemi devono supportare l'idea che un utente abbia diversi ruoli. Se non lo supporti, quando un Istruttore è un Amministratore o uno Studente, avranno troppi permessi per un dato contesto o semplicemente non funzioneranno correttamente, e dovranno usare un login diverso (cioè creare più identità, eventualmente coinvolgendo la gestione di più indirizzi e-mail) quando vogliono utilizzare il sistema da un ruolo diverso che svolgono.
Riguardo all'implementazione interna (dal tuo commento a @Joppe), l'uso dell'ereditarietà (ad esempio, lo studente eredita dall'account) impedisce che una persona giochi più ruoli. Questo dovrebbe usare invece la composizione. Parlando filosoficamente, non diremmo che "A Student is-a (n) Account".
Potresti considerare una pagina di identità, che dà all'utente l'accesso ai vari ruoli e amp; contesti che hanno. Quindi consentire loro di scegliere un ruolo (o contesto) e procedere con le autorizzazioni e il controllo di accesso associati a quel ruolo per il resto della loro sessione. Dovrebbero essere in grado di cambiare i ruoli tornando alla loro pagina di identità.