La méthode principale ne doit-elle être constituée que de créations d'objets et d'appels de méthodes?

Un de mes amis m'a dit que la meilleure pratique est que la mainméthode contenant la classe doit être nommée Mainet ne contient que la mainméthode. De plus, la mainméthode ne doit analyser que les entrées, créer d'autres objets et appeler d'autres méthodes. La Mainclasse et la mainméthode ne devraient rien faire d'autre. Fondamentalement, ce qu'il dit que la mainméthode contenant la classe devrait être comme:

public class Main
{
    public static void main(String[] args)
    {
        //parse inputs
        //create other objects
        //call methods
    }
}

Est-ce la meilleure pratique?

Le point que fait valoir votre ami est qu'une application doit simplement être amorcée par la méthode principale, et rien de plus. En ayant la méthode principale dans sa propre classe, vous renforcez simplement ce fait en la gardant indépendante de toute logique d'application. Le rôle de la méthode principale serait d'analyser toutes les entrées et d'initialiser l'application avec ces entrées, et éventuellement d'autres.

public static void main(String[] args){
    new Foo().start(args[0]);
}

L'idée est que vous n'avez pas besoin de la méthode principale pour initialiser Foo. Cela vous permet d'initialiser et de démarrer facilement Foodans un autre contexte, potentiellement avec une sémantique différente.

public Foo initSomewhereElse(String arg){
    Foo f = new Foo();
    f.start(arg);
    return f;
}

La méthode main () est un vilain retour à la programmation procédurale, fournissant le point d'entrée dans l'application. Des tentatives sont faites dans différents langages de programmation pour l'encapsuler, mais sa nature même rend cela difficile (il doit être public et statique, mais il ne doit JAMAIS être appelé à partir de quoi que ce soit d'autre dans le programme, ce qui est très contradictoire). WPF a réussi (en vous cachant main () profondément dans les entrailles du projet d'application WPF et en fournissant des "crochets" configurables pour le traitement personnalisé), tout comme Java (d'une manière similaire pour les applications Android), mais WinForms et la plupart des autres types de les applications vous permettent toujours de gérer main ().

Ainsi, la plupart des experts disent que le LOC de la fonction main () doit être aussi bas que possible. Il y a une approche (qui je pense est un peu exagérée) dans laquelle la fonction main () a une ligne:

public class Program
{
   private Program(string[] args)
   {
      //parse args and perform basic program setup
   }

   //Reduce the ugliness to the absolute minimum
   public static void main(string[] args)
   {
      new Program(args).Run();  
   }

   private void Run()
   {
      //kick off the driving O-O code for the app; i.e. Application.Run()
   }    
}

C'est un peu trop, mais je suis d'accord avec le principe de base; main () devrait aussi peu que possible pour mettre votre application orientée objet et événementielle dans un état "prêt".

Dans les langues qui prennent en charge les fonctions, mainc'est juste une fonction régulière et il n'y a donc rien d'autre que vous puissiez faire avec ce que vous avez dit. Et puis il y a des langages idiots qui abandonnent les fonctions en faveur de tout être un objet, ce qui signifie que chaque fois que vous voulez une fonction, vous devez l'envelopper dans une classe inutile .

Eh bien, assez décousu. Le point que j'essaye de faire est que ce Mainn'est pas vraiment une classe, mais une fonction et donc vous ne devriez rien faire d'autre que d'analyser les entrées, créer d'autres objets et appeler d'autres méthodes parce que c'est tout ce qu'une fonction peut faire.