Visualizzazione dei risultati da 1 a 10 su 38

Visualizzazione discussione

  1. #13
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da Jamie04 Visualizza il messaggio
    Ehm...non ricordavo nemmeno che i costruttori potessero essere privati!
    Sì, certo che possono.

    Quote Originariamente inviata da Jamie04 Visualizza il messaggio
    Vediamo se ho capito bene quello che hai detto:
    codice:
    public class Utente {
        private static final Utente FOUNDER=new Utente("Alan", "Turing", "Fondatore", new Date(12,5,23));
        
        //costruttore founder
        private Utente (String nome, String cognome, String nickname, Date dataNascita) {
    Il primo problema che mi si presenta è: come faccio a riferirmi a FOUNDER all'esterno di questa classe?
    Cioè, nella classe UtenteTest dove creo gli utenti del social network, il primo utente che creo come fa ad aver FOUNDER come utentePresentante?
    [...]
    invece ho capito che per riferirmi a FOUNDER nell'altra classe dovevo anteporre il nome della classe in cui risiede FOUNDER.
    Guarda che come stavi facendo è (quasi) tutto giusto, salvo il fatto che FOUNDER va messo public, altrimenti è ovvio che dall'esterno non è visibile.

    Una costante static può avere anche senso che sia privata, se serve solo internamente a quella classe ..... ma non è questo il tuo caso. E in altre classi va appunto usata come Utente.FOUNDER.

    Quote Originariamente inviata da Jamie04 Visualizza il messaggio
    Sono comunque in panne, ora non so come impedire che si istanzi un oggetto utente senza che abbia un riferimento a un utente presentante. Avevo pensato di risolvere col costruttore così fatto:
    codice:
        //costruttore utente
        public Utente (String nome, String cognome, String nickname, Date dataNascita, Utente utentePresentante) {
    Anche qui è (quasi) tutto giusto, tecnicamente. Il costruttore è giusto questo per creare un utente con un utente "presentante". Il fatto però è che devi testare utentePresentante e se null dovresti lanciare una eccezione, a tua scelta NullPointerException o IllegalArgumentException o una tua eccezione specifica (se vuoi o se richiesto).

    Quote Originariamente inviata da Jamie04 Visualizza il messaggio
    Ma a quanto pare non funziona comunque, perché se provo a creare un utente senza rif. a chi lo presenta, molto semplicemente non trova il costruttore e mi dà un errore.
    Non capisco il problema .... il costruttore è pubblico, se passi i parametri corretti come quantità, tipi, non vedo problemi.

    Quote Originariamente inviata da Jamie04 Visualizza il messaggio
    solo che sono costretta a istanziare il fondatore per forza nella classe utente e non in quella di test.
    Tecnicamente, di per sé, non c'è nulla di strano in quella costante. Come posto/momento di creazione è appropriata. Se ti lamenti del fatto che i dati nome, cognome ecc... devi per forza "cablarli" in Utente quando istanzi l'utente per FOUNDER ..... allora sì, ti do ragione.

    Una soluzione è usare un metodo di "factory", in Utente metti un metodo statico creaFounder che riceve i dati nome ecc... e ovviamente creaFounder deve poter creare 1 solo fondatore, quindi un campo static per il fondatore lo devi comunque tenere.

    Quote Originariamente inviata da Jamie04 Visualizza il messaggio
    ora dovrei fare in modo di inserire un controllo che faccia in modo che un utente può presentarne uno ed uno soltanto. quindi ogni utente può essere presentatore di un solo utente. un if nel costruttore?
    Qui allora o cambi radicalmente la architettura, ovvero crei una entità (=classe) SocialNetwork che contiene tutte le informazioni e associazioni tra utenti necessarie (e Utente modella solo più nome+cognome+nickname+dataNascita e basta).
    Oppure ...

    Tenendo la tua architettura attuale, in Utente aggiungi anche la informazione di utentePresentato (non solo utentePresentante). Perché? Pensaci .... così puoi legare i due utenti presentato e presentatore.
    Quando crei un nuovo utente passando un "presentatore" fai in modo che il utentePresentato di presentatore faccia riferimento al this del nuovo utente che stai creando. Così sono legati e se successivamente si tenta di creare un nuovo utente con quello stesso "presentatore", puoi verificare che il suo utentePresentato sia null o no.


    P.S. come ti è già stato detto, java.util.Date non è di per sé "deprecato" ... anzi, è una classe tutt'oggi ancora molto importante. Sono molti dei suoi metodi/costruttori che sono deprecati. Quindi non fare new Date(12,5,23).
    Se vuoi costruire facilmente un Date con g/m/a, fai una classe di utility es. DateUtils con un metodo statico che riceve g/m/a (in qualunque modo ti pare, int separati o anche in stringa unica) e crei un Date passando o da un parsing con (Simple)DateFormat (se parti con un String) o con un GregorianCalendar (se passi int separati).
    Ultima modifica di andbin; 25-10-2013 a 15:02
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2026 vBulletin Solutions, Inc. All rights reserved.