Pourquoi Java a-t-il des méthodes `void`?

Pourquoi / pourquoi Java doit-il avoir des voidméthodes? Référence :

Toute méthode déclarée vide ne renvoie pas de valeur.

Autant que je sache, chaque utilisation de voidserait mieux servie en renvoyant un indicateur d'état, l'objet invoqué ou null.

Cela ferait de chaque appel une instruction assignable et faciliterait les modèles de constructeur et l’enchaînement des méthodes. Les méthodes qui ne sont appelées que pour leurs effets renvoient généralement un type booléen ou générique Successou lèvent une exception en cas d'échec.

Parce qu'il y a une différence entre "Cette fonction peut réussir ou échouer et est suffisamment consciente d'elle-même pour pouvoir faire la différence" et "Il n'y a pas de retour d'information sur l'effet de cette fonction". Sans cela void, vous vérifieriez sans cesse les codes de réussite et croiriez que vous écrivez un logiciel robuste, alors que vous ne faites rien de la sorte.

1. Parce que C a un voidtype, et Java a été conçu pour suivre de nombreuses conventions de la famille de langage C.
2. Il existe de nombreuses fonctions pour lesquelles vous ne souhaitez pas que la valeur soit renvoyée. Qu'allez-vous faire avec "un Successtype générique " de toute façon? En fait, les valeurs renvoyées pour indiquer le succès sont encore moins importantes en Java qu'en C, car Java comporte des exceptions pour indiquer un échec, contrairement au C.

La raison initiale pour laquelle le langage a un voidtype est parce que, comme dans C, les créateurs du langage ne voulaient pas compliquer inutilement la syntaxe du langage avec des procédures et des fonctions identiques à celles de Pascal.

C'était la raison initiale.

Vos suggestions:

retourner un drapeau d'état

C'est un non-non. Nous n'utilisons pas d'indicateurs d'état. Si quelque chose ne va pas, nous le signalons via des exceptions.

l'objet invoqué

Le style courant des invocations est un développement récent. La plupart des programmeurs qui utilisent très bien couramment aujourd'hui et qui roulent des yeux s’ils doivent utiliser une interface qui ne la prend pas en charge ne sont même pas nés de la création de Java.

retourne null

Cela vous obligerait à déclarer une méthode comme renvoyant quelque chose, alors qu'en réalité, elle ne renvoie rien. Cela serait donc très déroutant pour quelqu'un qui cherche une interface à essayer de comprendre ce qu'elle fait. Les gens inventeraient inévitablement une classe par ailleurs inutile, qui signifie "aucune valeur de retour", de sorte que toutes les fonctions qui n'ont rien à renvoyer puissent renvoyer une référence nulle à une telle classe. Ce serait maladroit. Heureusement, il existe une solution à cela, il s'appelle void. Et c'est la réponse à votre question.

Certaines méthodes, comme System.out.printlnne retourne rien d’utile, mais s’appelle purement pour cet effet secondaire. voidest un indicateur utile pour le compilateur et pour le lecteur de code qu'aucune valeur utile n'est renvoyée.

Retourner nullau lieu de voidsignifie que vous obtiendrez simplement NullPointerExceptionle moment où vous utiliserez cette valeur pour quoi que ce soit. Donc, vous négociez une erreur de compilation pour une erreur d’exécution qui est bien pire. De plus, vous devrez définir le type de retour comme Objectétant trompeur et source de confusion. (Et l'enchaînement ne fonctionnerait toujours pas.)

Les codes d'état sont généralement utilisés pour indiquer des conditions d'erreur, mais Java a des exceptions à cette fin.

Renvoyer thisn'est pas possible à partir de méthodes statiques.

Renvoyer un Successobjet générique n'aurait aucun but utile.

L' une des raisons est qu'il peut être trompeur de revenir jamais autre chose que, par exemple, null. Exemple:

Que devrait Arrays.sort(a)revenir?

Si vous soutenez que cela adoit être renvoyé afin que l'appel puisse être chaîné (ce qui semble être votre réponse d'après votre question), il n'est alors plus clair si la valeur renvoyée est une copie de l'objet d'origine ou de l'objet d'origine lui-même. . Les deux sont possibles. Et oui, vous pouvez le mettre dans la documentation, mais c'est suffisamment ambigu pour ne pas créer d'ambiguïté.

D'autre part, si vous soutenez que cela nulldevrait être renvoyé, cela soulève la question de savoir quelle information la valeur renvoyée fournit éventuellement à l'appelant et pourquoi le programmeur devrait être obligé d'écrire return nulllorsqu'il ne transmet aucune information.

Et si vous revenez quelque chose d' autre tout à fait absurde (comme la longueur a), il fait juste utiliser cette valeur de retour vraiment déroutant - il suffit de penser combien plus confondant est - à - dire au int len = Arrays.sort(a)lieu de int len = A.length!

Renvoyer un booleanqui est toujours égal à truece que vous suggérez est non seulement inutile (la valeur de retour ne contient aucune information), mais serait en réalité trompeur. La plupart du temps, il est préférable d'utiliser les types de retour qui ne portent que le plus d' informations est en fait disponible - c'est pourquoi en Java que vous avez booleanpour true/ falseplutôt que de retourner un intavec 4 milliards de valeurs possibles. De même, renvoyer un booleanavec deux valeurs possibles où il n'y a qu'une seule valeur possible ("succès générique") serait trompeur.

Cela ajouterait également une surcharge de performances inutile.

Si une méthode est utilisée uniquement pour ses effets secondaires, il n'y a rien à renvoyer, et le type de retour voidreflète exactement cela. Les rares erreurs potentielles peuvent être signalées via des exceptions.

Une chose qui pourrait être améliorée, serait de créer voidun type réel, tel que celui de Scala Unit. Cela résoudrait certains problèmes tels que la gestion des génériques.

Java est une langue relativement ancienne. Et en 1995 (date de sa création) et peu de temps après, les programmeurs étaient très préoccupés par la durée pendant laquelle un processus prenait le contrôle du processeur ainsi que la consommation de mémoire. Le renvoi de vide éliminerait quelques cycles d'horloge et un peu de consommation de mémoire d'un appel de fonction, car vous n'auriez pas à mettre la valeur de retour sur la pile et vous ne seriez pas obligé de la supprimer par la suite.

Un code efficace ne vous restitue pas quelque chose que vous n'utiliseriez jamais. Par conséquent, mettre vide dans un objet qui a une valeur de retour sans signification est une bien meilleure pratique que de renvoyer une valeur de succès.

J'ai lu des arguments qui suggèrent que la deuxième option (retour this) devrait être l'approche au lieu de void. C'est une bonne idée, mais l'approche de type constructeur n'était pas populaire au moment de la création de Java. Si c'était aussi populaire à l'époque que maintenant, c'est peut-être l'approche qui a été adoptée. Revenir nullest une très mauvaise idée, OMI. Je souhaite nulln'était même pas dans la langue du tout.

Le problème est maintenant que si une méthode retourne une instance de son propre type, il n'est pas clair s'il s'agit d'un nouvel objet ou du même objet. Souvent, cela n'a pas d'importance (ou ne devrait pas l'être), mais d'autres fois, cela compte. Je suppose que le langage pourrait être modifié pour revenir implicitement thissur les méthodes void. Le seul problème auquel je peux penser pour le moment est que si la méthode était modifiée ultérieurement pour renvoyer un nouvel objet du même type, il n'y aurait pas d'avertissement de compilation, mais ce n'est peut-être pas grave. Le système de types actuel ne se soucie pas de ces types de changements maintenant. La manière dont cela interagit avec l'héritage / les interfaces nécessiterait une certaine réflexion, mais permettrait également aux anciennes API sans style constructeur d'être appelées comme si elles le faisaient.

Un autre aspect:

Java est un langage statique avec des fonctionnalités assez strictes. Cela signifie que beaucoup de choses qui seraient assez ouvertes ou dynamiques dans d'autres langues (c / f Ruby, Lisp, etc.) sont strictement déterminées.

Ceci est une décision de conception générale. Il est difficile de répondre au "pourquoi" (enfin, car les concepteurs de la langue ont pensé que ce serait bien!). Le "pour quoi" est assez clair: il permet au compilateur de détecter beaucoup d'erreurs, ce qui est généralement une très bonne fonctionnalité pour toutes les langues. Deuxièmement, il est relativement facile de raisonner sur la langue. Par exemple, il est relativement facile de créer des preuves de correction formelles dans (des sous-ensembles de) le langage Java; à titre de comparaison, cela serait pratiquement impossible dans un langage dynamique comme Ruby et al.

Cette pensée imprègne le langage, par exemple, la déclaration forcée d'exceptions possibles qu'une méthode peut générer, le type séparé de interfacevs classpour éviter un héritage multiple ambigu, etc. Pour ce qu’il est (langage du monde réel impératif statique et axé sur la gestion des erreurs de compilation), ces éléments sont en fait assez élégants et puissants. Ils se rapprochent des langages théoriques (scientifiques) qui sont conçus exprès pour explorer certaines de ces questions plus que tout autre langage du monde réel auparavant (à ce moment-là, pensez-vous).

Alors. Avoir un voidtype strict est un message clair: cette méthode ne retourne rien, point. C'est ce que c'est. Le remplacer par l'application forcée de toujours renvoyer quelque chose mènerait soit à un comportement beaucoup plus dynamique (comme en Ruby où chaque def a une valeur de retour explicite ou implicite, toujours), ce qui serait mauvais pour la prouvabilité et le raisonnement; ou à gonfler massif en utilisant un autre mécanisme ici.

(Et NB, Ruby (par exemple) gère différemment, et sa solution est toujours exactement comme acceptable que de Java, car il a une philosophie complètement différente. Par exemple , il jette prouvabilité et raisonnabilité complètement hors de la fenêtre tout en mettant un grand accent sur extrêmement haute expressivité de la langue.)