Sì, certo che possono.
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.
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).
Non capisco il problema .... il costruttore è pubblico, se passi i parametri corretti come quantità, tipi, non vedo problemi.
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.
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).


Rispondi quotando