Progettare classi che dipendono l'una dall'altra

2

Come si fa a progettare classi per un sistema in cui due componenti dipendono l'uno dall'altro?

Per un esempio più concreto, considera questo scenario, stai progettando un software per gestire studenti, insegnanti e classi in una struttura educativa. Per motivi di praticità, desideri che il tuo oggetto Class sia in grado di eseguire una query per Student s che sono registrati all'interno della sua istanza. Allo stesso tempo, ti piacerebbe sapere che cos'è Class es a Student è iscritto.

Un design semplice può includere un contenitore che contiene istanze di tipo Class nell'oggetto Student e un contenitore che contiene istanze di Student nell'oggetto Class . Fa il lavoro ma introduce una dipendenza ciclica tra le due classi. Di solito, questo è guardato dall'alto in basso [citazione necessaria], ma suona come un disegno valido in cui questo potrebbe essere utile. C'è una ragione per cui sarebbe una cattiva idea farlo? E in che modo questa situazione può essere corretta senza introdurre significativi costi generali delle prestazioni?

    
posta Khaled Nassar 15.12.2015 - 11:18
fonte

2 risposte

7

Osservando la relazione tra classi e studenti non è così semplice come le classi hanno una lista di studenti che partecipano e gli studenti hanno un elenco di classi a cui stanno partecipando.

Potrebbe essere necessario modellare gli studenti che non partecipano più a una lezione, le classi cancellate, gli studenti in lista di attesa ecc.

La soluzione migliore sarebbe una raccolta di iscrizioni. Ogni iscrizione potrebbe essere 'attiva', 'ritirata', 'classe cancellata', 'lista d'attesa' ecc. Puoi aggiungere nuovi tipi di iscrizione senza mai cambiare classi o classi di studenti.

La raccolta di iscrizione dispone quindi di metodi per ottenere una raccolta di classi o studenti.

Potrebbe trattarsi di qualcosa come enroll.Active(chem101) per ottenere gli studenti attivi per chimica 101 o enroll.DroppedOut(bent) per ottenere tutte le classi che Bent ha abbandonato a causa di spendere troppo tempo su stackexchange.

    
risposta data 15.12.2015 - 12:06
fonte
1

Il motivo principale per cui potrebbe essere una cattiva idea è mantenere la relazione a due vie in sincronia. Quando aggiungi una lezione a uno studente, devi anche aggiungere uno studente a una classe. Un altro, minore, problema è che la persistenza della relazione sarà solo una delle parti. Quindi dovresti convertirlo se fosse opposto nel modello.

Ci sono due passaggi per risolvere questo problema. In primo luogo è rendere le raccolte su Studente e Classe di sola lettura. Questo è generalmente semplice. Quindi, introdurre un terzo concetto. Può essere semplice come EnrollmentService, che consente di accoppiare gli Studenti alle Classi e garantisce internamente che la relazione sia mantenuta correttamente. Oppure può essere una propria entità come suggerisce Bent.

    
risposta data 15.12.2015 - 12:30
fonte

Leggi altre domande sui tag