Originariamente inviata da
andbin
Giusto una premessa, visto che non hai familiarità con le collection. Quelle che ho detto prima List/Set/Map/Queue sono le interfacce (quindi astrazioni "pure") principali delle 4 tipologie di collezioni. Poi per ciascuna esistono svariate implementazioni. ArrayList e LinkedList sono le due implementazioni più note di List (ma ne esistono altre).
Quindi ArrayList NON è una cosa diversa da List ... ArrayList è-un List nel senso della relazione di ereditarietà.
Ok, grazie per la precisazione.
Detto questo, invece riguardo le relazioni tra oggetti, mettiamola così. Se ragioniamo solo a livello di oggetti e loro relazioni (niente DB, ORM, ecc.. in ballo) se una asta deve avere nozione di N offerte, allora
è giusto che in un oggetto Asta ci sia un "insieme" (detto in generale, può essere come ripeto array o collezione) di riferimenti ad oggetti Offerta. Questo è sensato a livello object-oriented.
MapDB non lo conosco in dettaglio (so cosa è) quindi non so dire ora se ha requisiti specifici nei confronti degli oggetti. Tenere solo gli Id ... non è sbagliato di per sé ma richiede allora che ci sia una architettura in generale tale per cui sia facile "tirar su" gli oggetti da DB a fronte del loro Id (e viceversa). Altrimenti è poco utile.
Riflettendo meglio mi rendo conto che:
- ad un'asta possono corrispondere N offerte ma una specifica offerta può essere riferita ad una sola asta. Questo significa forse che sarebbe più sensato mettere in Offerta il riferimento all'asta ma è inutile tenere in Asta un arrayList di Offerte o comunque un qualsiasi riferimento ad Offerte...o no?
- ad un'asta possono corrispondere N domande e N risposte, e qui la cosa si complica... perché le risposte sono riferite sia alle domande che alle aste, le domande solo alle aste.
Non so che pesci pigliare 
Io avevo modellato queste classi così (ti metto solo le parti significative):
Classe Informazioni che si occupa di modellare le domande e le risposte:
codice:
public class Informazioni implements Serializable {
private static final long serialVersionUID = -1582157235274572596L;
private int id;
private String domanda;
private String risposta;
Classe Asta che modella le aste:
codice:
public class Asta implements Serializable {
private static final long serialVersionUID = 6884156563697118688L;
//informazioni inserite all'atto della creazione di una nuova asta
private int id; //id univoco per ogni asta.
private String venditore; //l'utente che ha inserito l'asta
private String nomeOggetto; //il nome dell'oggetto in vendita
private String descrizione; //la descrizione dell'oggetto in vendita
private String categoria; //categoria di appartenenza
private Double prezzoBase; //prezzo di partenza
private Date dataIns; //data di inserimento dell'asta
private Date scadenza;
private Boolean statoAsta; //chiusa o in corso
//informazione inserite successivamente
private Offerta offertaCorrente; //l'offerta attuale
private String vincitore; //l'utente che ha vinto l'asta (offerta più alta)
private Informazioni info; //le domande e le risposte
Classe che modella le Offerte:
codice:
public class Offerta implements Serializable {
private static final long serialVersionUID = 3725421945964525829L;
private String offerente; //l'utente che ha inserito l'offerta
private Double offerta;
Ma a questo punto mi sembra di aver sbagliato...
Peraltro mi chiedo: Asta deve sapere quali sono le sue offerte e le sue informazioni? Oppure è sufficiente che Offerta sappia a quale Asta si riferisce, e Informazioni sappia ugualmente a quale asta sono riferite?
Rispondi quotando