Explication détaillée du code de paramètre de longueur variable en Java

Jusqu'à J2SE1.4, il était impossible de définir une méthode avec un nombre variable de paramètres réels dans un programme Java - car Java exige que le nombre et le type de paramètres réels (Arguments) et de paramètres formels (Paramètres) doivent correspondent un par un, et le nombre de paramètres formels est fixé lors de la définition de la méthode. Bien qu'il soit possible de fournir des versions avec différents nombres de paramètres formels pour la même méthode via le mécanisme de surcharge, cela ne peut toujours pas atteindre l'objectif consistant à permettre aux quantités réelles de paramètres de changer arbitrairement.

Cependant, la sémantique de certaines méthodes exige qu'elles soient capables d'accepter un nombre variable de paramètres réels - par exemple, la célèbre méthode main doit pouvoir accepter tous les paramètres de ligne de commande comme étant réels. paramètres et la commande Le nombre de paramètres de ligne ne peut pas être déterminé à l'avance.

Pour ce problème, l'approche consistant à "utiliser un tableau pour envelopper les paramètres réels à transmettre" est traditionnellement utilisée pour résoudre ce problème. Cet article présente principalement l'explication détaillée du code des paramètres de longueur variable en Java, impliquant plusieurs problèmes tels que la méthode de définition du nombre variable de paramètres réels, l'enveloppement de tableau des paramètres réels, etc. Il a une certaine valeur de référence et les amis dans le besoin peuvent en apprendre davantage sur il.

1. Envelopper les paramètres réels avec des tableaux

La méthode « d'envelopper les paramètres réels avec des tableaux » peut être divisée en trois étapes : Premièrement, pour cette méthode, définissez un paramètre de tableau ; puis lors de l'appel, générez un tableau contenant tous les paramètres réels à transmettre ; enfin, transmettez ce tableau comme paramètre réel ;

Cette approche peut effectivement atteindre l'objectif de "permettre à la méthode d'accepter un nombre variable de paramètres", mais la forme de l'appel n'est pas assez simple.

J2SE1.5 fournit le mécanisme Varargs, vous permettant de définir directement des paramètres formels pouvant correspondre à plusieurs paramètres réels. Ainsi, un nombre variable de paramètres réels peut être transmis de manière plus simple.

La signification de Varargs

De manière générale, "Varargs" signifie "nombre d'arguments variable". Parfois, ils sont simplement appelés « arguments variables », mais comme ce nom n'explique pas ce qui est variable, la signification est un peu vague.

2. La méthode de définition d'un nombre variable de paramètres réels

Tant que le "type" et le "nom du paramètre" d'un Les paramètres formels sont En ajoutant trois "." consécutifs (c'est-à-dire "...", les points de suspension dans la phrase en anglais), vous pouvez le faire correspondre à des paramètres réels incertains. Une méthode avec de tels paramètres formels est une méthode avec un nombre variable de paramètres réels.

Listing 1 : Une méthode avec un nombre variable de paramètres réels

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

Notez que seul le dernier Les paramètres formels peuvent être définis comme « correspondant à un nombre indéterminé de paramètres réels ». Par conséquent, il ne peut y avoir qu’un seul paramètre de ce type dans une méthode. De plus, si cette méthode a d’autres paramètres formels, mettez-les au premier plan.

Le compilateur convertira secrètement ce dernier paramètre formel en paramètre de tableau et mettra une marque dans le fichier de classe compilé pour indiquer qu'il s'agit d'une méthode avec un nombre variable de paramètres réels.

Listing 2 : Forme secrète d'une méthode avec nombre variable de paramètres réels

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

Parce qu'il y a Une telle conversion, vous ne pouvez donc plus définir une méthode pour cette classe qui ait la même signature que la méthode convertie.

Listing 3 : Combinaisons qui provoqueront des erreurs de compilation

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

3. Appeler une méthode avec un nombre variable de paramètres réels

Tant que vous écrivez les paramètres réels à passer un par un dans les positions correspondantes, vous pouvez appeler une méthode avec un nombre variable des paramètres réels. Aucune autre étape n’est requise.

Listing 4 : Plusieurs paramètres réels peuvent être transmis

sumUp(1,3,5,7);

En coulisses, le compilateur convertira ce processus d'appel en "tableau encapsulant les paramètres réels" " sous la forme :

Listing 5 : Création de tableau qui apparaît secrètement

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

De plus, le "nombre incertain" évoqué ici comprend également zéro, donc comme ça L'appel de , est équivalent à ceci :

Listing 7 : L'argument zéro correspond à un tableau vide

sumUp();

Notez qu'un tableau vide est passé au lieu de null . De cette façon, il peut être traité sous une forme unifiée sans avoir à détecter à quelle situation il appartient.

4. Traitement d'un nombre variable de paramètres réelssumUp(newint[]{});

Comment gérer un nombre variable de paramètres réels et traiter les paramètres réels du tableau. la méthode est fondamentalement la même. Tous les paramètres réels sont enregistrés dans un tableau portant le même nom que les paramètres formels. Selon les besoins réels, après avoir lu les éléments de ce tableau, vous pourrez les cuire à la vapeur ou les faire bouillir à votre guise.

Listing 8 : Traitement des paramètres réels reçus

5. Transférer un nombre variable de paramètres réels

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

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

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

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

public class PrintfSample {
 public static void main(String[] args) {
  printOut("Pi:%f E:%f\n", Math.PI, Math.E);
 }
 private static void printOut(String format, Object... args) {
  System.out.printf(format, args);
 }
}

6.是数组？不是数组？

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

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

清单10：一个“cannotbeappliedto”的编译错误

private static void testOverloading(int[] i) {
System.out.println("A");
}
public static void main(String[] args) {
testOverloading(1, 2, 3);//编译出错
}

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

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

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

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

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

清单11：当Varargs遇上泛型

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

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

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

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

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

8.重载中的选择问题

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

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

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

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

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

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

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

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

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

在引入了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) {
	}
}

另外，因为J2SE1.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) {
	}
}

9.归纳总结

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

以上内容就是关于Java中可变长度参数代码详解的全部内容，希望能帮助到大家。

相关推荐：

PHP 程序员快速进行Java 开发

10 个 有趣的 JavaScript 的脚本语言

如何使用Java定时器Timer

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!