답변

Varargs는 메서드가 같은 유형의 가변(임의) 개수의 인자를 받아들이도록 허용하는 특별한 문법입니다. 메서드 선언에서 이러한 매개변수는 Type... name으로 표시됩니다(예: int... nums). 메서드 내부에서는 인자가 일반 배열로 인식됩니다.

예시:

public void printNumbers(int... nums) {
    for (int n : nums) {
        System.out.print(n + " ");
    }
}

호출하는 방법:

printNumbers(1, 2, 3, 4);
// 또는
printNumbers();

내부 구현: varargs로 메서드를 호출하면 컴파일러가 자동으로 해당 유형의 배열을 생성합니다.

제한 사항 및 주의점:

• Varargs 매개변수는 하나만 있을 수 있으며 항상 매개변수 목록의 마지막이어야 합니다.
• Varargs 확장(Type...)은 본질적으로 배열(Type[])입니다.
• null 전송: printNumbers(null)은 반복을 시도할 때 NPE를 발생시킵니다.
• Varargs의 메서드 오버로딩은 호출의 모호성을 초래할 수 있습니다.

함정 질문

질문: "여러 varargs 매개변수가 있는 메서드를 선언할 수 있습니까?"

자주 틀리는 점: 많은 사람들이 public void example(int... a, String... b)와 같이 선언할 수 있다고 생각하지만, 이는 컴파일 오류를 발생시킵니다.

정답: 아니요, varargs 매개변수는 하나만 가능하며 마지막이어야 합니다.

주제의 세부사항 미비로 인한 실제 오류 사례

---

이야기

기업의 로깅 라이브러리에서 varargs와 배열을 사용하는 오버로드된 버전을 구현했습니다. 배열을 전달할 때 요소 집합 대신 잘못된 메서드가 호출되어 배열이 객체로 로깅되고 그 내용이 나타나지 않았습니다. 이는 로그 분석 시 혼란을 초래했습니다.

---

이야기

통합 서비스에서 varargs가 null을 수용하며 NPE를 확인하지 않았습니다. 요소 반복을 시도할 때 시스템이 예상치 못하게 "크래시"가 발생했습니다. 최소한의 빈 배열이 예상되었기 때문입니다.

---

이야기

한 전자상거래 프로젝트에서 메서드 오버로딩에 혼란을 겪었습니다: send(String subject, String... emails)라는 메서드와 send(String subject, String[] emails)라는 메서드가 있었습니다. 배열을 전달할 때 컴파일러가 잘못된 메서드를 선택했습니다. 결과: 이메일이 고객에게 발송되지 않았습니다.