Void et al.

"안녕하세요, 아미고! 작고 흥미로운 주제가 하나 더 있습니다. 공허 유형입니다."

"그런데 왜 그런 유형이 필요한 거죠? 제 말은 무효를 이해합니다. 함수와 절차를 정렬하는 것입니다. 절차는 없지만 무효(아무것도)를 반환하는 함수는 있습니다."

"네, 하지만 Ellie가 최근에 Callable 인터페이스에 대해 말한 것을 기억하십니까?"

"예."

"그리고 유형 인수로 전달해야 하는 것이 무엇인지도 기억하십니까?"

"예, 반환 값의 유형:"

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

"맞아요. 그러면 call 메서드가 int를 반환하도록 하려면 어떻게 해야 할까요? 그 다음에는요?"

"이제 저는 이것에 대한 오토박싱이 있다는 것을 알고 있습니다. 정수만 전달하면 모든 것이 시계처럼 진행될 것입니다."

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

"훌륭합니다. 그리고 메서드가 아무것도 반환하지 않으면 어떻게 될까요?"

"요지는 알겠습니다. 그럼 우리는 Void를 Void의 대응물로 사용하는 건가요?"

"네."

"반환 값을 객체로 만든 다음 null을 반환하는 것이 더 쉽지 않을까요?"

"가끔이지만 항상 그런 것은 아닙니다."

"객체를 작성할 때 실제로 여기서 void를 반환하려고 했다는 것을 알지만 다른 프로그래머는 이것을 모르고 null을 반환하는 이유를 생각할 것입니다."

"또는 메서드를 호출하는 코드는 반환 값을 예상합니다."

"하지만 Void를 작성하면 여전히 null을 반환해야 하지만 모두가 이것이 void에 대한 래퍼라는 것을 즉시 이해합니다."

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

"흠. 네 말이 맞아. 항상 null을 반환하는 메서드는 문제가 있다. 하지만 Void로 선언된 메서드는 추가 설명 없이도 이를 수행할 수 있다."

"코드 가독성이 우선입니다. 저는 Java를 좋아합니다!"

"좋습니다. 마음에 드셨다니 다행입니다. 오늘은 이만 마치겠습니다."