web-dev-qa-db-fra.com

Pourquoi la méthode principale en Java a-t-elle toujours besoin d'arguments?

Pourquoi la méthode principale en Java a-t-elle toujours besoin d'arguments? Pourquoi devrions-nous écrire String[] args à chaque fois, au lieu de l'écrire lorsque nous utilisons des arguments?

Une telle méthode génère une erreur de compilation Main method not found. Puisque nous n'utilisons jamais d'arguments de la méthode principale, cela devrait être autorisé.

public static void main()
{
}

Ce n'est pas une question d'entrevue. Je viens de penser à la programmation.

24
dejavu

Fondamentalement, il y a quatre réponses:

  1. Parce que c'est comme ça que ça a été conçu. Oui, je sais que c'est une raison circulaire. Mais le fait est que c'est comme ça et que ça ne va pas changer. Donc, à moins que vous ne prévoyiez concevoir votre propre langue, la question est sans objet.

  2. Propreté de la conception (principe de DRY). Ne spécifiez pas deux signatures de point d’entrée quand on peut faire le travail. Et clairement, ça peut.

  3. Simplicité sémantique. Supposons (hypothétiquement) que Java a supporte les deux points d’entrée void main(String[]) et void main(). Que se passerait-il si une classe définissait les deux méthodes? Est-ce une erreur? Si non, lequel est prioritaire en cas d'ambiguïté? Est-ce encore déroutant?

    En n'autorisant que void main(String[]), le JLS évite le problème.

  4. Ceci est analogue aux signatures standard de point d’entrée C et C++. (Certes, certains environnements d'exécution C/C++ prennent également en charge d'autres points d'entrée non standard ... mais ce n'est pas vraiment une bonne chose ... IMO.)

Rien de tout cela ne signifie qu'il aurait été carrément faux de le faire autrement. Et par exemple, C # vous propose des signatures alternatives et résout le problème de l'ambiguïté en demandant au développeur de désigner un point d'entrée d'une autre manière. 

FWIW, cette page wikipedia décrit la méthode "principale" dans un certain nombre de langues.

31
Stephen C

Parce que l'outil Java qui exécute l'application recherche un main avec une signature spécifique, de sorte qu'il sait qu'il appelle la bonne. Java a une surcharge de méthode, donc lorsque vous recherchez une méthode, vous devez spécifier une signature assez complète. Accorder l'outil Java pourrait faire quelque chose de plus complexe (recherchez la signature spécifique et, ne l'ayant pas trouvée, recherchez toute main et appelez-la si elle n'en trouve qu'une), mais ce n'est pas ce que les concepteurs de Java ont décidé de faire (et subjectivement, FWIW, je pense que c'est pour le mieux - restons simple).

Vous trouverez les détails dans la spécification du langage Java, Chapitre 12: Exécution . Et notez qu'à partir de quand Java a obtenu des listes d'arguments variables, il est devenu possible de déclarer main de deux manières différentes:

public static void main(String[] args)
// or
public static void main(String... args)
5
T.J. Crowder

C'est juste la façon dont ils l'ont conçu. Corollaire à cela, vous vous demanderez peut-être pourquoi son cousin (C #) autorise la méthode Main avec ou sans paramètres, c'est simplement la façon dont ils l'ont conçue.

Il n'y a pas de raison sérieuse ici, chaque concepteur de langue a ses préférences, principes auxquels vous devez souscrire. Parfois, c’est à nous d’en déduire ou d’adhérer (parfois, nous ne pouvons pas tout faire comme nous le voulons) pendant ce temps.

Hmm ... cela me rappelle le système d'exploitation que j'utilise actuellement. Avant OS X Lion, vous ne pouvez redimensionner que dans le coin inférieur droit de la fenêtre. Cela fait plus de 28 ans d'attente avant de pouvoir enfin redimensionner la taille des fenêtres de leur système d'exploitation.

Même si j'aime trop Mac OS, je ne voudrais pas défendre leur position avant qu'une fenêtre ne puisse être redimensionnée que sur un coin. Le fanatisme est une chose, mais l'adhésion aveugle en est une autre.

C’est donc une bonne chose que vous pratiquiez la pensée critique et ne croyiez pas aveuglément que la signature de la méthode principale de Java est le seul moyen correct


Une digression, attendre que Mac ait des bords redimensionnables à n'importe quel angle me revient à attendre que Java ait une propriété de première classe. Malgré le nom JSON (JavaNotation d’objet de script, bien que Javascript ne soit bien sûr pas Java), l’initialiseur d’objet C # (via sa propriété initializer et son initialiseur de collection) a plus d’affinité avec JSON que l’initialiseur d’objet Java avec JSON. L'initialiseur d'objet C # est très net et ressemble beaucoup à JSON.

C #

var p = new {
    Lastname = "Lennon",
    Firstname = "John",
    PlacesBeen = 
        new[]
        {
            new { City = "Liverpool", Country = "England" },
            new { City = "New York", Country = "US" },
            new { City = "Tokyo", Country = "Japan" }
        }
};

return Json(p);

Javascript:

var p = {
    "Lastname" : "Lennon",
    "Firstname" : "John",
    "PlacesBeen" :             
        [
            { "City" : "Liverpool", "Country" : "England" },
            { "City" : "New York", "Country" : "US" },
            { "City" : "Tokyo", "Country" : "Japan" }
        ]
};

Par conséquent, avec la propriété de première classe de C # (et non la méthode) et l’initialiseur de collection, le code devient non seulement concis et ordonné, mais il ressemble maintenant beaucoup à ce que la plupart des développeurs utilisent actuellement pour le format d’échange de données, JSON.

La syntaxe d'initialisation d'objet de Java est très éloignée du style JSON. Je ne défendrai pas la décision de conception de Java (syntaxe/conception de propriété, par exemple) à cet égard :-)

Donc, dans la même veine que je ne défendrai pas la décision de conception du concepteur de langage Java sur la syntaxe/conception de la propriété Java, je ne défendrai pas public static void main(String[] args)

0
Michael Buen

Lorsque la machine virtuelle Java commence à exécuter le programme Java, elle recherche la méthode principale ayant cette signature (tableau i.e String).

0
Android Killer