[OOP] Consigli per modificare un programma

[Mex87]

Salve ragazzi, avrei un piccolo dubbio sul modo di procedere con la OOP :muro: , in pratica durante un colloquio mi hanno chiesto:

"Consideriamo un programma che gestisce le visite in un ambulatorio,
il programma registra le visite ed insieme ai dati della visita registra l'identificativo del medico che ha svolto l'esame.

Adesso, devi aggiungere una funzionalità, ogni volta che visualizziamo una visita, oltre al titolo della visita dobbiamo visualizzare il nome del medico che l'ha svolta.

Consideriamo le visite rappresentate da una classe contenente tutti i campi della tabella, come procedi?"

Inizialmente ho risposto, che avendo l'id del medico disponibile nella classe visita, ogni volta che visualizziamo una visita carichiamo il medico corrispondente all'id e ne visualizziamo il nome.

E l'esaminatore mi ha risposto con un "bene, ma in questo modo dobbiamo fare una query per richiamare il nome del medico ad ogni visualizzazione, anche se parliamo della stessa visita" :doh:

Ed io rispondo dicendo "Per evitare questo possiamo modificare la classe Visita aggiungendo la proprietà Nome_Medico in modo da legare il nome del medico con la visita."

E la questione è finita li, ma vorrei sapere ho risposto correttamente?, esiste un modo migliore per risolvere il problema?

[U-Boat]

La prima risposta che hai dato era più che buona, nel senso che inizialmente non ti devi preoccupare troppo di problemi prestazionali.

Il punto successivo è su come ottimizzare il numero di interrogazioni al DB e in questo caso hai una vasta scelta di pattern: vai delle associazioni lazy (in stile rails/activerecord) oppure eager, alle identity map, giusto per citare le prime che mi vengono in mente.

In questo caso non c'è una scelta migliore o peggiore in assoluto, ma tutto dipende dal tipo di applicazione (web, client/server ...), da quanti accessi concorrenti ti aspetti, se esiste già un ORM o meno ecc....

La risposta che hai dato, secondo me, è un po' infelice, perchè aggiungi un campo a una classe del modello per una richiesta specifica della vista; tant'è che se un'altra vista volesse mostrare la data di nascita del medico dovresti andare a toccare ancora la classe visita, che è un approccio che normalmente si evita, salvo casi particolari

[nico159]

"I dati ci dicono chiaramente che stiamo lavorando in un settore monopolizzato da Oracle...il problema delle prestazioni si risolve inserendo nel budget un server Oracle SPAR...utilizzando una materialized view" :sofico:

Secondo me, avresti dovuto prima chiedere più informazioni sul problema ed il suo contesto
Completamente d'accordo con quanto detto da U-Boat

[Mex87]

Grazie per le risposte :asd: , il punto è che per la seconda risposta sapevo benissimo che in questo modo snaturavo l'oggetto visita, ma li per li sul momento ( ed anche ora :muro: :muro: ) non sono riuscito a pensare ad un modo per avere i dati del medico in memoria associati alla visita senza doverli ricaricare ogni volta dal database.

Ho pensato a creare un oggetto Medico da caricare quando carico la visita e da usare quando serve, ma mi è parsa poco pratica come soluzione e molto soggetta a bug.

Dato che il medico deve essere allegato per forza alla visita ho pensato anche di estendere la classe visita con i dati che mi servono del medico, ma non mi convinceva come soluzione.:confused:

[U-Boat]

Estendere la classe (nel senso di extends Java) non è una buona idea, anzi... dal punto di vista logico tu hai visita associata a medico, quindi hai due oggetti indipendenti che sono legati tra di loro da una relazione; non ha nessun senso estendere visita per aggiungere il medico, già ce l'hai.

La soluzione di caricare il medico insieme alla visita è invece ragionevole e all'atto pratico si fa proprio così, soprattutto in ambito web dove gli oggetti tendono a vivere giusto il tempo di gestire la richiesta e a non essere persistenti in memoria.

Riesci a spiegare perchè, secondo te, è una soluzione poco pratica e soggetta a bug?

[Mex87]

Il punto di caricare il medico ogni volta in cui carico la visita, mi sembra soggetto a bug, perchè questo significa cercare nell'intero programma l'istruzione di caricamento visita per aggiungere subito dopo l'istruzione di caricamento medico.

Mi sembra macchinosa come soluzione...:stordita: per il resto ho pochissima esperienza, ed è facile che abbia scritto vaccate. :help:

[wingman87]

Secondo me, il problema di dover effettuare una query in più è un non problema, basterebbe mantenere una cache dei medici, che per loro natura non dovrebbero essere oggetti particolarmente mutevoli. E se anche fosse necessaria una query, probabilmente sarebbe su una delle tabelle più piccole del db e su un campo che dovrebbe essere indicizzato, quindi dal costo irrisorio.

[U-Boat]

Ti faccio un esempio molto semplificato per dimostrarti che il concetto non è così complicato e alla fine è anche molto pulito.
Utilizzo un linguaggio pseudo-java, chiaramente questo esempio non compila nemmeno e mancano molti dettagli necessari


class Medico {
private String nome;
// altri campi...

public static Medico find(int id) {
Result result = executeQuery('SELECT * FROM medici WHERE id = ?', id)
return new Medico(result)
}

public Medico(...) {
// imposta i campi
}
}



class Visita {
private int idMedico;
private Medico medico

public static Visita find(int id) {
Result result = executeQuery('SELECT * FROM visite WHERE id = ?', id)
return new Visita(result)
}

public Visita(...) {
// imposta i campi
}

public Medico getMedico() {
if (this.medico == null) {
this.medico = Medico.find(this.idMedico)
}
return this.medico
}
}


La classe Visita è un esempio classico di caricamento lazy dell'associazione, dove cioè l'oggetto Medico viene estratto dal db solo se richiesto.
In alternativa puoi implementare un metodo find diverso che carica il medico direttamente.

[Daniels118]

L'esempio di U-Boat è ottimo, per completezza vorrei aggiungere un'ottimizzazione.
Nell'esempio il metodo Medico.find(id) restituisce un oggetto diverso ad ogni chiamata, anche se l'id è lo stesso. Questo significa che se abbiamo due visite fatte dallo stesso medico, ognuna di esse punterà in realtà a due istanze diverse dello stesso medico. Se modifichiamo ad esempio il reparto del medico ottenuto da una visita, lo stesso medico ottenuto dall'altra visita continuerà ad avere il vecchio reparto. Se immaginiamo addirittura il caso di modificare campi diversi sulle due istanze e poi invocare i metodi per la loro persistenza, solo uno dei due campi verrà effettivamente modificato sul DB.
Per ovviare a questo problema è sufficiente conservare la cache del medico in un posto comune, non all'interno delle visite, ma come membro di una mappa statica all'interno della classe Medico. Modifico il codice di U-Boat, sempre in pseudo-codice:


class Medico {
private static Map medici = new Map();
private String nome;
// altri campi...

public static Medico find(int id) {
if (! medici.hasItem(id) {
Result result = executeQuery('SELECT * FROM medici WHERE id = ?', id)
medici.add(id, new Medico(result))
}
return medici.get(id)
}

public Medico(...) {
// imposta i campi
}
}



class Visita {
private int idMedico;

public static Visita find(int id) {
Result result = executeQuery('SELECT * FROM visite WHERE id = ?', id)
return new Visita(result)
}

public Visita(...) {
// imposta i campi
}

public Medico getMedico() {
return Medico.find(this.idMedico)
}
}

[Mex87]

Grazie tantissimo per questa idea!!!, io al massimo per adesso sarei arrivato fino all'implementazione di U-Boat.
Non avrei mai pensato di richiamare dalla classe visita la classe medico!

Si vede che ne ho strada da fare XD!

Inviato dal mio Nexus 7 utilizzando Tapatalk