Giammarco ha scritto:
mi viene detto che l'oggetto della classe "nuovo"(appena creato) non ha un determinato campo. Poi però, data una condizione (es. è un vaso di fiori), il campo deve esserci.
Il punto, lo ripeto, è che un campo o è stato previsto fin dall'inizio (definito cioè nel sorgente) oppure non esiste. Non è possibile avere un oggetto che all'inizio
non ha un campo X e poi dopo per qualche condizione particolare ce l'ha ... magicamente.
Java funziona così. In Javascript invece un oggetto può non avere subito una proprietà e poi successivamente averla ma semplicemente perché in Javascript gli oggetti sono (detto grossolanamente) una "mappa" di proprietà. In Java no.
Giammarco ha scritto:
non mi va bene pensare che quel vaso ha "0 fiori", perché è concettualmente sbagliato.
Può non andare bene per gli obiettivi che ti sono stati posti o per chi ti ha richiesto la realizzazione di questa cosa ma ... di per sé, in senso generale, non è affatto "sbagliato".
Giammarco ha scritto:
Il problema se guardo solo al risultato è risolvibile facilmente in altri modi, posso gestirlo e avere una risposta adeguata senza problemi, forse anche in meno tempo e in meno righe di codice. Il mio obiettivo era quello di capire se era possibile fare una cosa del genere, al di là dell'efficienza o meno dell'operazione. Concludo che non è possibile?
Se pensiamo solo a livello di campo, si potrebbe avere un campo Integer, che quindi può essere null magari per indicare concettualmente "non c'è questa informazione". Che sarebbe un pelino diverso da un valore 0 ma in ogni caso il campo
esiste.
Una alternativa è la ereditarietà: una classe Vaso (senza campo per il numero di fiori) e una
sotto classe VasoConFiori che ha appunto un campo per il numero di fiori.
Se istanzio un Vaso non devo passare nulla, se istanzio un VasoConFiori devo passargli il numero di fiori. Il punto è che se ho un oggetto Vaso, non posso certo "trasformarlo" in VasoConFiori e viceversa.
Quindi mi viene da pensare che nemmeno questo ti possa servire.