深入了解JAVA可变长度的参数(Varargs)

        Java1.5增加了新特性：可变参数：适用于参数个数不确定，类型确定的情况，java把可变参数当做数组处理。注意：可变参数必须位于最后一项。当可变参数个数多余一个时，必将有一个不是最后一项，所以只支持有一个可变参数。因为参数个数不定，所以当其后边还有相同类型参数时，java无法区分传入的参数属于前一个可变参数还是后边的参数，所以只能让可变参数位于最后一项。

可变参数的特点：

（1）只能出现在参数列表的最后； 
（2）位于变量类型和变量名之间，前后有无空格都可以；
（3）调用可变参数的方法时，编译器为该可变参数隐含创建一个数组，在方法体中一数组的形式访问可变参数

实践

1. 定义实参个数可变的方法

        只要在一个形参的“类型”与“参数名”之间加上三个连续的“.”（即“...”，英文里的句中省略号），就可以让它和不确定个实参相匹配。而一个带有这样的形参的方法，就是一个实参个数可变的方法。

清单1：一个实参个数可变的方法  

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

        编译器会在背地里把这最后一个形参转化为一个数组形参，并在编译出的class文件里作上一个记号，表明这是个实参个数可变的方法。

清单2：实参个数可变的方法的秘密形态
       

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

清单3：会导致编译错误的组合

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

2. 调用实参个数可变的方法

         只要把要传递的实参逐一写到相应的位置上，就可以调用一个实参个数可变的方法。不需要其它的步骤。

清单4：可以传递若干个实参

sumUp(1, 3, 5, 7);

          在背地里，编译器会把这种调用过程转化为用“数组包裹实参”的形式：

清单5：偷偷出现的数组创建

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

          另外，这里说的“不确定个”也包括零个，所以这样的调用也是合乎情理的：

清单6：也可以传递零个实参

sumUp();

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

清单7：零实参对应空数组

sumUp(new int[]{});

        注意这时传递过去的是一个空数组，而不是null。这样就可以采取统一的形式来处理，而不必检测到底属于哪种情况。

3. 处理个数可变的实参

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

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

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

4. 是数组？不是数组？

       尽管在背地里，编译器会把能匹配不确定个实参的形参，转化为数组形参；而且也可以用数组包了实参，再传递给实参个数可变的方法；但是，这并不表示“能匹配不确定个实参的形参”和“数组形参”完全没有差异。
      一个明显的差异是，如果按照调用实参个数可变的方法的形式，来调用一个最后一个形参是数组形参的方法，只会导致一个“cannot be applied to”的编译错误。

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

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

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

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

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

        J2SE 1.5中新增了“泛型”的机制，可以在一定条件下把一个类型参数化。例如，可以在编写一个类的时候，把一个方法的形参的类型用一个标识符（如T）来代表，至于这个标识符到底表示什么类型，则在生成这个类的实例的时候再行指定。这一机制可以用来提供更充分的代码重用和更严格的编译时类型检查。  
        不过泛型机制却不能和个数可变的形参配合使用。如果把一个能和不确定个实参相匹配的形参的类型，用一个标识符来代表，那么编译器会给出一个“generic array creation”的错误。

清单11：当Varargs遇上泛型

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

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

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

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

6. 重载中的选择问题

       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");
	}
}

清单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) {}
}

清单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) {}
}

归纳总结

        和“用数组包裹”的做法相比，真正的实参个数可变的方法，在调用时传递参数的操作更为简单，含义也更为清楚。不过，这一机制也有它自身的局限，并不是一个完美无缺的解决方法。