Consente di concentrarsi su un oggetto di dominio correlato a più altre entità (diverse!). A volte abbiamo bisogno di una relazione e talvolta di un'altra. Siamo agili e diciamo: non sappiamo in anticipo quante altre relazioni ci saranno.
In altre parole: abbiamo oggetto A correlato uno a uno a B e uno-a-molti a C e ancora one-to-one a D e così via. Ora, quando si sviluppa il livello di presentazione, spesso è necessario visualizzare molti dati; come tabella di A con B o in un altro posto A con molti C e così via.
Come modelleremo queste relazioni?
Ecco un esempio: Competition . A volte viene e deve essere utilizzato con ad es. %codice%. A volte con es. %codice%. Dato che ti interessano le prestazioni, diciamo anche che gli oggetti correlati ( Venue e lista di List<Event> s) provengono dal metodo / metodo finder / metodo finder / un join SQL (comunque lo chiami) - e che può essere iniettato in Venue usando alcuni strumenti di mappatura. In questo modo esprimiamo la relazione effettiva tra le entità.
Domanda: dovremmo mantenere entrambe le relazioni / riferimenti nella classe Event e ignorare l'altra quando ne viene usata una, oppure dovremmo creare molte classi separate, una per ogni relazione? (Non importa se è 1-1 o 1-molti, la domanda è la stessa.)
In altre parole, dovremmo avere:
[A]
Tutto nella singola classe. I metodi Getter rappresentano le relazioni. È su di noi riempire l'oggetto se la relazione è necessaria.
class Competition {
... competition data...
private Venue venue;
public Venue getVenue() {
return venue;
}
private List<Event> events;
public List<Event> getEvents() {
return events;
}
}
Ma poi, quando il metodo dell'applicazione restituisce un Competition non sai quali relazioni sono popolate e devi capirlo guardando il codice dei metodi dell'applicazione o il nome del metodo (es. Competition ).
[B]
Per ogni relazione abbiamo un tipo o un'interfaccia. Un modo per farlo, senza interfacce per la semplicità di questo esempio, è:
class CompetitionVenue extends Competition {
private Venue venue;
public Venue getVenue() {
return venue;
}
}
e
class CompetitionEvents extends Competition {
private List<Event> events;
public List<Event> getEvents() {
return events;
}
}
Ora il tipo parla da solo quale rapporto viene restituito e quindi il metodo dell'applicazione che lo restituisce garantisce che la relazione esiste. Ma poi ogni relazione avrebbe una sua classe o interfaccia;
EDIT:
[C]
Ogni relazione è rappresentata utilizzando una classe generica come Competition e findCompetitionWithEvents...() non ha il getter per la lista di eventi?