Quanto è sbagliato avere più associazioni tra classi?

Questa domanda mostra che il tuo modello attuale non è intuitivo e penso che sia un buon feeling. Lascia che ti spieghi un'alternativa all'aver solo Student , Subject e Degree per te che, si spera, ti sembra più intuitivo.

Mentre uno studente sembra sapere tutto sui suoi gradi, non lo fa. Illustriamo questo con un esempio del mondo reale: considera che uno studente ha una laurea per un corso. Tuttavia, lo staff universitario ha scoperto e può dimostrare che lo studente ha imbrogliato nelle prove finali. La sua laurea viene quindi dichiarata immediatamente non valida prima che probabilmente ne venga a conoscenza.

La domanda è: chi è responsabile di dire se alcuni studenti sono già in possesso e validi?

Sono quelli che hanno la responsabilità di sapere quale studente ha quali (validi) gradi. Questo potrebbe ad es. essere un examination office , ma potrebbe dipendere dall'università / paese. [1]

Come vedi, dobbiamo modellare un'altra parte in merito alla separazione delle preoccupazioni. E lo stesso vale per il tuo single degree plan . Esiste sicuramente un'altra autorità responsabile dell'amministrazione dei piani di laurea degli studenti per assicurarsi che ogni studente abbia un solo piano e che questo piano sia valido.

In poche parole, gli studenti e i loro gradi sono collegati solo indirettamente attraverso diversi tipi di autorità. Gli studenti di solito conoscono le autorità che sono responsabili per loro (ad esempio nel codice che significa che hanno un riferimento a questo oggetto).

[1]: solo una nota di cautela: anche se potrebbe esserci un'unica autorità di questo tipo, non modellarla con qualche schema singleton. Invece, modellalo come se ci potesse essere più di una autorità e nel tuo programma attuale crea solo un'istanza.

Se vuoi associare Student a Degree , ma tenerli separati l'uno dall'altro, puoi esprimere quella relazione con una struttura dati come una HashMap.

qualcosa come (non testato, trattalo come pseudo codice):

HashMap<Student, Degree> enrolment = new HashMap<Student, Degree>();
Student dave = new Student();
Degree masterOfScience = new Degree();
enrolment.put(dave, masterOfScience);

Primo: che cosa dovrebbe fare il programma? Non puoi prendere decisioni sull'architettura senza conoscere lo scopo del programma. Inoltre, ignora i consigli di persone a cui non hai detto lo scopo del programma:)

Secondo: a meno che tu non stia scrivendo una simulazione reale di un college, probabilmente non vuoi che gli oggetti come Studente, Soggetto ecc. abbiano comportamenti e responsabilità. In es. un programma amministrativo per un college, entità come studenti e lauree sono i dati su cui agisce il sistema, non gli oggetti che agiscono nel sistema. Per le entità di dati non devi pensare alle responsabilità, ma a quali dati devi tenere traccia per fare in modo che il sistema adempia ai suoi compiti.

Non cadere nella trappola per pensare che gli oggetti che agiscono nel sistema dovrebbero in qualche modo rappresentare oggetti del mondo reale. Questo è solo il caso del software di simulazione, che è una nicchia molto specifica. Nella maggior parte dei software, gli oggetti con comportamento (soggetti a principi come separazione delle preoccupazioni e responsabilità singola) saranno cose come "DatabaseConnection", "UI Control", "Report Scheduler" ecc. Che non hanno corrispondenza con oggetti del mondo reale ma piuttosto corrisponde ai compiti che l'applicazione è progettata per fare.

Studente, Soggetto e Laurea non sono direttamente correlati. A StudentDegree avrebbe la conoscenza e la portata di conoscere gli studenti, le materie e il loro grado. Un soggetto non dovrebbe tracciare ciò che ogni studente ha segnato. Dovrebbe essere uno StudenteSoggetto. Uno studente dovrebbe avere uno StudentDegree. A StudentDegree ha uno Studente e molti StudentiSoggetti e Laurea. Ora hai le relazioni corrette in modo che il comportamento possa essere centralizzato per il corso di laurea di uno studente.