Void et al.

"Hej, Amigo! Jeg har endnu et lille og interessant emne til dig. Void-typen."

"Og hvorfor skulle du bruge sådan en type? Jeg mener, jeg forstår void: det er for at bringe funktioner og procedurer på linje. Vi har ikke procedurer, men vi har funktioner, der returnerer void (intet)."

"Ja, men kan du huske, at Ellie for nylig fortalte dig om Callable-grænsefladen?"

"Ja."

"Og husker du også, hvad du skal bestå som et typeargument?"

"Ja, typen af ​​returværdien:"

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

"Godt. Og hvad hvis du vil have opkaldsmetoden til at returnere en int? Hvad så?"

"Nu ved jeg, at der er autoboxing til dette. Jeg ville bare bestå et heltal, og alt vil gå som smurt:"

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

"Fremragende. Og hvad nu hvis metoden ikke skulle returnere noget?"

"Jeg forstår din pointe. Så bruger vi Void som modstykke til void?"

"Ja."

"Ville det ikke være nemmere bare at gøre returværdien til et objekt og derefter returnere null?"

"Nogle gange, men ikke altid."

"Du ved, du virkelig havde til hensigt at returnere ugyldigt her, da du skrev Object, men en anden programmør ved det måske ikke og vil tænke, hvorfor du returnerer null."

"Eller koden, der kalder metoden, vil forvente en returværdi."

"Men når du skriver Void, forstår alle straks, at dette er en indpakning for tomhed, selvom du stadig skal returnere null."

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

"Hmm. Du har ret. En metode, der altid returnerer null, rejser spørgsmål. Men metoden, der er erklæret som Void, kan gøre dette uden at kræve yderligere forklaring."

"Kodelæsbarhed kommer først. Jeg kan godt lide Java!"

"Fint. Jeg er glad for, at du kan lide det. Vi er færdige for i dag."