Lucadf89 ha scritto:
Propongo un cambio di approccio al problema,
Se lo scopo è avere un Oggetto che gestisca dei dati comuni (nome, cognome, codice fiscale, iban) e un dato che classifica l'oggetto (impiegato,responsabile,ecc) forse l'approccio migliore non è quello di estendere la classe ma avere due classi distinte indipendenti.
Chiariamo innanzitutto una cosa: l'utente iniziale aveva un dubbio (più che legittimo) sulla
ereditarietà e nei post precedenti non si è mai parlato di "database".
Lucadf89 ha scritto:
(e mettiamo anche un metodino che a fronte di un codice mi dia la descrizione)
public String descrizioneTipoUtente(String codice) {
if(codice==this.codice) {
return this.descrizione;
}
return null;
}
Questo metodino, di fatto NON ha alcun senso. Già quel codice==this.codice non è una buona cosa è funziona "guarda caso" solo perché in Utente fai:
tipoUtente.descrizioneTipoUtente(tipoUtente.getCodice());
per cui è ovvio che quel codice è lo
stesso oggetto e == dà true.
Quindi quello che hai scritto è INAPPROPRIATO. Non serve.
Lucadf89 ha scritto:
Classe Utente
public class Utente {
private String nome=null;
private String cognome=null;
private String codFis=null;
private String iban=null;
private String tipologia=null;
Precisiamo innanzitutto che avere due entità Utente e TipoUtente di per sè è GIUSTO, non c'è nulla di sbagliato. Se vuoi fare la classe Utente in modo "sensato" le possibilità sono due:
a) In Utente tieni il CODICE del tipo utente (NON la descrizione!!):
public class Utente {
private String nome;
private String cognome;
private String codFis;
private String iban;
private String codiceTipoUtente; // <------
oppure
b) In Utente tieni il riferimento all'oggetto TipoUtente:
public class Utente {
private String nome;
private String cognome;
private String codFis;
private String iban;
private TipoUtente tipoUtente; // <------
Tenere
solo la descrizione è inutile e non ha senso, perché non puoi più "legare" l'utente al suo tipo utente.
Lucadf89 ha scritto:
Un approccio simile si usa se hai una applicazione che si appoggia su un db in quel caso si gestiscono le classi in maniera differente ma simile a quanto descritto.
Ribadisco ancora che non è il tuo approccio che è sbagliato. È assolutamente più che ragionevole avere una tabella "utente" e un'altra tabella "tipo utente". Ma si tratta di un design ben differente.
La ereditarietà invece serve per un altro motivo: per "specializzare" il comportamento. Se Responsabile estende Impiegato, magari ci deve essere un metodo che fa un qualche calcolo o logica particolare che in Responsabile è ridefinito per farlo in maniera diversa o più specifica. Qui la ereditarietà è utile.
E comunque il fatto di avere una gerarchia di classi, NON preclude certo l'uso (lettura/scrittura) con un database. Anche se ovviamente servono degli accorgimenti più specifici.
Lucadf89 ha scritto:
Avremmo quindi due tabelle una tipoUtente e una Utente, quest'ultima con un outerJoin sulla tabella Utente.
Non voglio sembrare pignolo (beh, sì ... lo so) ma ... non sono le tabelle ad evere gli inner/outer join. La scelta del join la fai a livello di query.
Nelle tabelle al massimo ci sono delle
foreign key ovvero colonne designate in modo specifico per fare riferimento ad un'altra colonna in un'altra tabella.
Quindi nello scenario descritto, la tabella Utente potrebbe avere una colonna cod_tipo_utente (foreign key) che fa riferimento alla colonna codice della tabella Tipo_Utente. Se la colonna cod_tipo_utente in Utente è
not-nullable (cosa più che ragionevole), vuol dire che un Utente ha sempre una tipologia (anche qui, ragionevole/sensato). Pertanto a livello di query basta un normale join ("inner") verso Tipo_Utente.
Conclusioni: studia un po' di più ..