Java의 Varargs 메커니즘 이해-java지도 시간-php.cn

J2SE 1.5는 "Varargs" 메커니즘을 제공합니다. 이 메커니즘을 사용하면 여러 실제 매개변수와 일치할 수 있는 형식 매개변수를 정의할 수 있습니다. 따라서 다양한 수의 실제 매개변수를 더 간단한 방법으로 전달할 수 있습니다. 이 문서에서는 이 메커니즘을 사용하는 방법과 이 메커니즘이 배열, 제네릭 및 오버로드와 상호 작용할 때 발생하는 몇 가지 문제를 소개합니다.

J2SE 1.4까지는 Java 프로그램에서 가변 개수의 실제 매개변수로 메소드를 정의하는 것이 불가능했습니다. 왜냐하면 Java에서는 실제 매개변수(Arguments)와 형식 매개변수(Parameters)의 수와 유형을 요구하기 때문입니다. )은 하나씩 일치해야 하며 형식 매개변수의 수는 메소드 정의 시 고정됩니다. 오버로딩 메커니즘을 사용하여 동일한 메소드에 대해 다양한 수의 형식 매개변수가 있는 버전을 제공할 수 있지만, 이는 여전히 실제 매개변수 양을 임의로 변경하도록 허용하는 목적을 달성할 수 없습니다.

그러나 일부 메서드의 의미론에서는 가변 개수의 실제 매개변수를 허용할 수 있어야 합니다. 예를 들어 유명한 기본 메서드는 모든 명령줄 매개변수를 실제 매개변수로 허용할 수 있어야 하며 명령줄 매개변수 개수는 미리 결정할 수 없습니다.

이 문제에 대해서는 전통적으로 "배열을 사용하여 전달할 실제 매개변수를 래핑하는" 접근 방식을 사용하여 문제를 해결합니다.

실제 매개변수를 배열로 래핑

"실제 매개변수를 배열로 래핑"하는 방법은 세 단계로 나눌 수 있습니다. 먼저 이 방법에 대한 배열 매개변수를 정의합니다. 그런 다음 호출 시 전달할 실제 매개변수를 모두 포함하는 배열을 생성하고, 마지막으로 이 배열을 실제 매개변수로 전달합니다.

이 접근 방식은 "메서드가 다양한 수의 매개 변수를 허용하도록 허용"한다는 목적을 효과적으로 달성할 수 있지만 호출 형식은 충분히 간단하지 않습니다.

J2SE 1.5는 Varargs 메커니즘을 제공하므로 여러 실제 매개변수와 일치할 수 있는 형식 매개변수를 직접 정의할 수 있습니다. 따라서 다양한 수의 실제 매개변수를 더 간단한 방법으로 전달할 수 있습니다.

Varargs의 의미

일반적으로 "Varargs"는 "변수의 수"를 의미합니다. 단순히 "가변인수"라고도 부르는데, 이 용어는 가변이 무엇인지 설명하지 않기 때문에 의미가 조금 모호합니다.

실제 매개변수의 가변 개수를 정의하는 방법

형식 매개변수의 "유형"과 "매개변수 이름" 사이에 ""를 연속으로 3개만 추가하면 됩니다. (즉, 영어 문장의 줄임표 "...") 불확실한 개수의 실제 매개변수와 일치시킬 수 있습니다. 이러한 형식 매개변수를 사용하는 방법은 가변 개수의 실제 매개변수를 사용하는 방법입니다.

목록 1: 가변 개수의 실제 매개변수가 있는 메소드

private static int sumUp(int... values) {    
}

로그인 후 복사

마지막 형식 매개변수만 정의할 수 있습니다. "불확실한 수의 실제 매개변수를 일치시킬 수 있게" 됩니다. 따라서 메소드에는 그러한 매개변수가 하나만 있을 수 있습니다. 또한, 이 메소드에 다른 형식 매개변수가 있는 경우 이를 맨 앞에 배치하십시오.

컴파일러는 비밀리에 이 마지막 형식 매개변수를 배열 매개변수로 변환하고, 컴파일된 클래스 파일에 표시를 넣어 이것이 실제 매개변수의 개수가 가변적인 메소드임을 나타냅니다.

목록 2: 가변 개수의 실제 매개변수를 갖는 메소드의 비밀 형식

private static int sumUp(int[] values) {    
}

로그인 후 복사

이러한 변환으로 인해 다음을 수행할 수 있습니다. 더 이상 변환된 메서드와 동일한 시그니처를 사용하여 이 클래스에 대한 메서드를 정의하지 않습니다.

목록 3: 컴파일 오류를 일으키는 조합

private static int sumUp(int... values) {   
}   

private static int sumUp(int[] values) {   
}

로그인 후 복사

빈 생존 문제

J2SE 1.5 구문에 따름 , "..." 앞의 공백 문자는 선택 사항입니다. 이런 식으로 작성하는 방법에는 두 가지가 있습니다. "..." 앞에 공백 문자를 추가하는 것("Object... args"로 형성됨)과 "..." 앞에 공백 문자를 추가하지 않는 것("로 형성됨)입니다. 개체...args"). 현재 J2SE 1.5와 호환되는 Java Code Convention은 공식적으로 발표되지 않았기 때문에 어떤 작성 방식이 더 정통적인지 알 수 없습니다. 그러나 배열 매개 변수는 "Object [] args"와 "Object[] args"의 두 가지 방법으로 작성할 수도 있고 "[]" 앞에 공백 문자를 추가하지 않는 전통적인 작성 방식을 사용하는 것으로 보입니다. 공백이 없는 "Object...args" "작성 방식이 전반적으로 더 조화로워졌습니다.

실제 매개변수의 개수가 가변적인 메소드 호출

전달하려는 실제 매개변수가 해당 위치에 하나씩 쓰여지면 가변적인 수의 실제 매개변수를 갖는 메소드 가변 메소드. 다른 단계는 필요하지 않습니다.

목록 4: 여러 가지 실제 매개변수를 전달할 수 있음

sumUp(1, 3, 5, 7);

로그인 후 복사

컴파일러는 비밀리에 이 호출 프로세스를 다음 형식으로 변환합니다. "실제 매개변수를 배열로 래핑":

목록 5: 비밀리에 나타나는 배열 생성

sumUp(new int[]{1, 2, 3, 4});

로그인 후 복사

또한 여기에 " "불확실한 숫자"에도 0이 포함되므로 이러한 호출은 합리적입니다.

목록 6: 실제 매개변수 0개를 전달할 수도 있습니다

sumUp(); 

这种调用方法被编译器秘密转化之后的效果，则等同于这样：

로그인 후 복사

목록 7: 빈 배열에 해당하는 0개의 인수

sumUp(new int[]{});

로그인 후 복사

이번에는 null이 아닌 빈 배열이 전달됩니다. 이렇게 하면 어떤 상황에 속하는지 파악하지 않고도 통일된 형태로 처리할 수 있습니다.

4. 处理个数可变的实参

处理个数可变的实参的办法，和处理数组实参的办法基本相同。所有的实参，都被保存到一个和形参同名的数组里。根据实际的需要，把这个数组里的元素读出之后，要蒸要煮，就可以随意了。

清单8：处理收到的实参们

private static int sumUp(int... values) {   
    int sum = 0;   
    for (int i = 0; i < values.length; i++) {   
        sum += values[i];   
    }   
    return sum;   
}

로그인 후 복사

5. 转发个数可变的实参

有时候，在接受了一组个数可变的实参之后，还要把它们传递给另一个实参个数可变的方法。因为编码时无法知道接受来的这一组实参的数目，所以“把它们逐一写到该出现的位置上去”的做法并不可行。不过，这并不意味着这是个不可完成的任务，因为还有另外一种办法，可以用来调用实参个数可变的方法。

在J2SE 1.5的编译器的眼中，实参个数可变的方法是最后带了一个数组形参的方法的特例。因此，事先把整组要传递的实参放到一个数组里，然后把这个数组作为最后一个实参，传递给一个实参个数可变的方法，不会造成任何错误。借助这一特性，就可以顺利的完成转发了。

清单9：转发收到的实参们

public class PrintfSample {   

    public static void main(String[] args) {   
        // 打印出“Pi:3.141593 E:2.718282”   
        printOut("Pi:%f E:%f/n", Math.PI, Math.E);   
    }   

    private static void printOut(String format, Object... args) {   
        // J2SE 1.5里PrintStream新增的printf(String format, Object... args)方法   
        System.out.printf(format, args);   
    }   
}

로그인 후 복사

Java里的“printf”和“sprintf”

C语言里的printf（按一定的格式输出字符串）和sprintf（按一定的格式组合字符串）是十分经典的使用Varargs机制的例子。在 J2SE 1.5中，也分别在java.io.PrintStream类和java.lang.String类中提供了类似的功能。

按一定的格式输出字符串的功能，可以通过调用PrintStream对象的printf(String format, Object… args)方法来实现。

按一定的格式组合字符串的工作，则可以通过调用String类的String format(String format, Object… args)静态方法来进行。

6. 是数组？不是数组？

尽管在背地里，编译器会把能匹配不确定个实参的形参，转化为数组形参；而且也可以用数组包了实参，再传递给实参个数可变的方法；但是，这并不表示“能匹配不确定个实参的形参”和“数组形参”完全没有差异。

一个明显的差异是，如果按照调用实参个数可变的方法的形式，来调用一个最后一个形参是数组形参的方法，只会导致一个“cannot be applied to”的编译错误。

清单10：一个“cannot be applied to”的编译错误

private static void testOverloading(int[] i) {   
    System.out.println("A");   
}   

public static void main(String[] args) {   
    testOverloading(1, 2, 3);// 编译出错   
}

로그인 후 복사

由于这一原因，不能在调用只支持用数组包裹实参的方法的时候（例如在不是专门为J2SE 1.5设计第三方类库中遗留的那些），直接采用这种简明的调用方式。

如果不能修改原来的类，为要调用的方法增加参数个数可变的版本，而又想采用这种简明的调用方式，那么可以借助“引入外加函数（Introduce Foreign Method）”和“引入本地扩展（Intoduce Local Extension）”的重构手法来近似的达到目的。

7. 当个数可变的实参遇到泛型

J2SE 1.5中新增了“泛型”的机制，可以在一定条件下把一个类型参数化。例如，可以在编写一个类的时候，把一个方法的形参的类型用一个标识符（如T）来代表，至于这个标识符到底表示什么类型，则在生成这个类的实例的时候再行指定。这一机制可以用来提供更充分的代码重用和更严格的编译时类型检查。

不过泛型机制却不能和个数可变的形参配合使用。如果把一个能和不确定个实参相匹配的形参的类型，用一个标识符来代表，那么编译器会给出一个“generic array creation”的错误。

清单11：当Varargs遇上泛型

private static <T> void testVarargs(T... args) {   
    // 编译出错   
}

로그인 후 복사

造成这个现象的原因在于J2SE 1.5中的泛型机制的一个内在约束——不能拿用标识符来代表的类型来创建这一类型的实例。在出现支持没有了这个约束的Java版本之前，对于这个问题，基本没有太好的解决办法。

不过，传统的“用数组包裹”的做法，并不受这个约束的限制。

清单12：可以编译的变通做法

private static <T> void testVarargs(T[] args) {   
    for (int i = 0; i < args.length; i++) {   
        System.out.println(args[i]);   
    }   
}

로그인 후 복사

8. 重载中的选择问题

Java支持“重载”的机制，允许在同一个类拥有许多只有形参列表不同的方法。然后，由编译器根据调用时的实参来选择到底要执行哪一个方法。

传统上的选择，基本是依照“特殊者优先”的原则来进行。一个方法的特殊程度，取决于为了让它顺利运行而需要满足的条件的数目，需要条件越多的越特殊。

在引入Varargs机制之后，这一原则仍然适用，只是要考虑的问题丰富了一些——传统上，一个重载方法的各个版本之中，只有形参数量与实参数量正好一致的那些有被进一步考虑的资格。但是Varargs机制引入之后，完全可以出现两个版本都能匹配，在其它方面也别无二致，只是一个实参个数固定，而一个实参个数可变的情况。

遇到这种情况时，所用的判定规则是“实参个数固定的版本优先于实参个数可变的版本”。

清单13：实参个数固定的版本优先

public class OverloadingSampleA {   

    public static void main(String[] args) {   
        testOverloading(1);// 打印出A   
        testOverloading(1, 2);// 打印出B   
        testOverloading(1, 2, 3);// 打印出C   
    }   

    private static void testOverloading(int i) {   
        System.out.println("A");   
    }   

    private static void testOverloading(int i, int j) {   
        System.out.println("B");   
    }   

    private static void testOverloading(int i, int... more) {   
        System.out.println("C");   
    }   
}

로그인 후 복사

如果在编译器看来，同时有多个方法具有相同的优先权，它就会陷入无法就到底调用哪个方法作出一个选择的状态。在这样的时候，它就会产生一个 “reference to 被调用的方法名 is ambiguous”的编译错误，并耐心的等候作了一些修改，足以免除它的迷惑的新源代码的到来。

在引入了Varargs机制之后，这种可能导致迷惑的情况，又增加了一些。例如现在可能会有两个版本都能匹配，在其它方面也如出一辙，而且都是实参个数可变的冲突发生。

清单14：左右都不是，为难了编译器

public class OverloadingSampleB {   

    public static void main(String[] args) {   
        testOverloading(1, 2, 3);// 编译出错   
    }   

    private static void testOverloading(Object... args) {   
    }   

    private static void testOverloading(Object o, Object... args) {   
    }   
}

로그인 후 복사

另外，因为J2SE 1.5中有“Autoboxing/Auto-Unboxing”机制的存在，所以还可能发生两个版本都能匹配，而且都是实参个数可变，其它方面也一模一样，只是一个能接受的实参是基本类型，而另一个能接受的实参是包裹类的冲突发生。

清单15：Autoboxing/Auto-Unboxing带来的新问题

public class OverloadingSampleC {   

    public static void main(String[] args) { /* 编译出错 */  
        testOverloading(1, 2); /* 还是编译出错 */  
        testOverloading(new Integer(1), new Integer(2));   
    }   

    private static void testOverloading(int... args) {   
    }   

    private static void testOverloading(Integer... args) {   
    }   
}

로그인 후 복사