Vuoto et al.

"Ciao, Amigo! Ho un altro argomento piccolo e interessante per te. Il tipo Vuoto."

"E perché avresti bisogno di un tipo del genere? Voglio dire, capisco void: è per allineare funzioni e procedure. Non abbiamo procedure, ma abbiamo funzioni che restituiscono void (niente)."

"Sì, ma ti ricordi che Ellie ti ha recentemente parlato dell'interfaccia Callable?"

"SÌ."

"E ti ricordi anche cosa devi passare come argomento di tipo?"

"Sì, il tipo del valore restituito:"

class EmptyJob implements Callable
{
 public String call() throws Exception
 {
  return null;
 }
}

"Giusto. E se volessi che il metodo call restituisca un int? E allora?"

"Ora so che c'è l'autoboxing per questo. Vorrei solo passare un numero intero e tutto andrà come un orologio:"

class EmptyJob implements Callable
{
 public Integer call() throws Exception
 {
  return null;
 }
}

"Eccellente. E se il metodo non dovesse restituire nulla?"

"Ho capito. Allora usiamo Void come controparte di void?"

"Sì."

"Non sarebbe più semplice rendere il valore restituito un oggetto e quindi restituire null?"

"Qualche volta, ma non sempre."

"Sai che intendevi davvero restituire void qui quando hai scritto Object, ma un altro programmatore potrebbe non saperlo e penserà perché stai restituendo null."

"Oppure il codice che chiama il metodo si aspetterà un valore restituito."

"Ma quando scrivi Void, tutti capiscono immediatamente che si tratta di un involucro per void, anche se devi comunque restituire null."

class EmptyJob implements Callable
{
 public Void call() throws Exception
 {
  return null;
 }
}

"Hmm. Hai ragione. Un metodo che restituisce sempre null solleva delle domande. Ma il metodo dichiarato come Void può farlo senza richiedere ulteriori spiegazioni."

"La leggibilità del codice viene prima di tutto. Mi piace Java!"

"Fantastico. Sono contento che ti piaccia. Per oggi abbiamo finito."