Avere più di un costruttore

[Jamie04]

Ho risolto l'errore di GWT nel frattempo. Avrei un'altra domanda, sempre sui costruttori.
C'è differenza tra questa istruzione:

return id;
e
return this.id;
?
Grazie!

[andbin]

    public Asta(int id, String venditore, String nomeOggetto, String descrizione, String categoria, Double prezzoBase, Date dataIns, Date scadenza, Boolean statoAsta) {
        this(id, venditore, nomeOggetto, descrizione, categoria, prezzoBase, dataIns, scadenza, statoAsta, null, "", null);
    }

Sì, corretto!

C'è differenza tra questa istruzione:

return id;
e
return this.id;
?

Se in quel punto lì "id" può essere SOLO il field (campo) di istanza, allora no, NON fa differenza. Il this è "implicito".

Se invece in quel punto ci fosse "in scope" una variabile/parametro locale chiamata id, allora per referenziare il campo (e non la variabile locale che "nasconde" il campo) DEVI usare this.id

[Jamie04]

Volevo solo segnalarvi che per motivi che ignoro non riesco a vedere gli ultimi messaggi di questo thread, né loggandomi né senza farlo. L'ultimo che vedo è il mio delle 19.33 del 20/01.

[Jamie04]

Ora che ho inserito quest'ultimo delle 18:05 vedo anche i precedenti.
Nel frattempo avrei un'altra domanda.
Ogni asta può avere svariati messaggi (informazioni, cioè domande e risposte) che la riguardano, perché gli utenti che vedono un'asta possono mandare richieste di chiarimento, a cui può rispondere ovviamente solo il venditore. Parimenti, ogni asta può avere molte offerte.
Alla luce di questo, mi stavo chiedendo se l'asta così come l'ho modellata vada bene.
Mi sta venendo il dubbio che i campi che possono essere "multipli", cioè Informazioni e Offerta fondamentalmente, non debbano essere ArrayList. Ed in caso, di che tipo dovrebbero essere? Grazie!

[andbin]

Ora che ho inserito quest'ultimo delle 18:05 vedo anche i precedenti.

Sì, capita anche a me a volte di non vedere i miei stessi messaggi. Ma non saprei dire il perché ..

Alla luce di questo, mi stavo chiedendo se l'asta così come l'ho modellata vada bene.

Per quanto detto da te, allora no, non va bene, non è sufficiente.

Mi sta venendo il dubbio che i campi che possono essere "multipli", cioè Informazioni e Offerta fondamentalmente, non debbano essere ArrayList. Ed in caso, di che tipo dovrebbero essere? Grazie!

Se una asta è associata a N offerte, allora un oggetto Asta deve mantenere i riferimenti ad N oggetti Offerta. Come ... con array o collezione (collezione preferibile rispetto ad array).
Le collezioni del framework sono di 4 categorie: List, Set, Map e Queue. Se conosci le loro caratteristiche ... non hai problemi a scegliere quale.

[Jamie04]

Ho visto che una persona ha usato un ArrayList di Integer (id) perché presumibilmente in Asta mantiene solo il riferimento (id) all'oggetto Offerta, stessa cosa per le informazioni. Per la persistenza i dati sono salvati tutti in un database di MapDB di tipo ConcurrentNavigableMap (non mi chiedere perché :-)). Pensi che così possa andar bene? Grazie ancora. Purtroppo non ho molta familiarità con le collection, quindi non saprei se una di loro sia meglio rispetto ad un ArrayList.

[andbin]

Ho visto che una persona ha usato un ArrayList di Integer (id) perché presumibilmente in Asta mantiene solo il riferimento (id) all'oggetto Offerta, stessa cosa per le informazioni. Per la persistenza i dati sono salvati tutti in un database di MapDB di tipo ConcurrentNavigableMap (non mi chiedere perché :-)). Pensi che così possa andar bene? Grazie ancora. Purtroppo non ho molta familiarità con le collection, quindi non saprei se una di loro sia meglio rispetto ad un ArrayList.

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à.

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.

[Jamie04]

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:

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:

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:

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?

[andbin]

- 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?

Dipende .... nel senso che a livello di relazioni tra oggetti è perfettamente possibile (e sensato) avere una o entrambe le seguenti cose:
- un oggetto Asta ha il riferimento a N oggetti Offerta
- un oggetto Offerta ha il riferimento all'oggetto Asta relativa

Quale delle due (o se entrambe le cose) tenere, dipende molto da COSA ci devi fare con quelle informazioni. Se un requisito della applicazione è di fare ad esempio frequenti ricerche/elaborazioni sulle offerte di una certa asta .... allora conviene tenere in Asta i riferimenti alle offerte. Altrimenti ti dai la classica zappa sui piedi ...

- 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.

Mettiamola così. Se una domanda è associata all'asta e a quella domanda è associata solo una singola risposta, allora HA senso fare una classe (es. Questione) che contiene domanda e risposta. E poi l'Asta avrebbe N oggetti Questione.

[Jamie04]

Le specifiche dicono più o meno questo:

- il sito deve permettere agli utenti non registrati di visualizzare gli oggetti in vendita elencati per data di scadenza, cliccando su un oggetto (di un'asta non ancora scaduta) si accede ad una pagina dove ci sono la descrizione dell'oggetto, l'attuale offerta più alta e le domande e risposte relative a quell'oggetto (uso asta e oggetto come sinonimi)

- gli utenti registrati possono, in più, inserire un'offerta per un oggetto in vendita, fare domande su un oggetto in vendita e rispondere a domande sugli oggetti che hanno posto loro in vendita, visualizzare la propria pagina profilo in cui possono vedere l'elenco degli oggetti per i quali hanno effettuato un'offerta (con indicazione dello stato: asta chiusa e oggetto aggiudicato, asta in corso e offerta migliore, asta in corso e offerta superata, asta chiusa e oggetto non aggiudicato) e gli oggetti che hanno posto in vendita (con indicazione dello stato: asta in corso, asta conclusa)

- quando l'asta è conclusa, gli oggetti non devono più apparire nella lista degli oggetti in vendita ma solo nelle pagine profilo del venditore e di chi ha partecipato all'asta

- solo l'amministratore del sistema potrà: cancellare un'asta, cancellare un'offerta, cancellare domande e risposte.

Alla luce di queste specifiche, come pensi che dovrei modellare quelle classi? Grazie ancora.