Il metodo principale dovrebbe consistere solo in creazioni di oggetti e chiamate di metodi?


12

Un mio amico mi ha detto che, la migliore pratica è che il mainmetodo contenente classe debba essere chiamato Maine contenga solo mainmetodo. Inoltre il mainmetodo dovrebbe analizzare solo input, creare altri oggetti e chiamare altri metodi. La Mainclasse e il mainmetodo non dovrebbero fare nient'altro. Fondamentalmente quello che sta dicendo che il mainmetodo contenente classe dovrebbe essere come:

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

È la migliore pratica?


6
Cos'altro può fare?
Pubblico

Risposte:


11

Il punto che il tuo amico sta facendo è che un'applicazione dovrebbe essere semplicemente avviata dal metodo principale e niente di più. Avendo il metodo principale nella sua classe, stai semplicemente rafforzando quel fatto mantenendolo indipendente da qualsiasi logica applicativa. Il ruolo del metodo principale sarebbe quello di analizzare qualsiasi input e inizializzare l'applicazione con quegli input, e possibilmente altri,.

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

L'idea è che non è necessario il metodo principale per inizializzare Foo. Ciò consente di inizializzare e avviare facilmente Fooin un altro contesto, potenzialmente con semantica diversa.

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

7

Il metodo main () è un brutto ritorno alla programmazione procedurale, fornendo il punto di ingresso nell'applicazione. Tentativi sono fatti in vari linguaggi di programmazione per incapsularlo, ma la sua stessa natura lo rende difficile (deve essere pubblico e statico, ma non dovrebbe MAI essere chiamato da qualsiasi altra cosa nel programma, che è altamente contraddittoria). WPF è riuscito (nascondendoti main () nelle viscere del progetto dell'applicazione WPF e fornendo "hook" configurabili per l'elaborazione personalizzata), così come Java (in un modo simile per le app Android), ma WinForms e molti altri tipi di le app ti fanno ancora gestire main ().

Pertanto, la maggior parte degli esperti afferma che il LOC della funzione main () dovrebbe essere il più basso possibile. C'è un approccio (che penso sia leggermente eccessivo) in cui la funzione main () ha una riga:

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()
   }    
}

Questo è un po 'troppo, ma sono d'accordo con il principio di base; main () dovrebbe fare il meno possibile per portare la tua applicazione orientata agli oggetti, guidata dagli eventi, in uno stato "pronto".


Non sono d'accordo. Può essere utile chiamare mainda altri contesti, ad esempio la ricorsione.
DeadMG

4
Personalmente, se stai ricorrendo al tuo metodo principale, penso che dovresti invece chiamare un altro metodo e ricorrere a quello. Solo nei contesti più semplici (app per console di complessità / difficoltà a livello di compiti a casa) sarebbe accettabile chiamare main () dall'interno del programma, e la definirei una situazione banale.
KeithS

1

Nelle lingue che supportano le funzioni mainè solo una funzione regolare e quindi non c'è nient'altro che tu possa farci a parte quello che hai detto. E poi ci sono linguaggi idioti che abbandonano le funzioni a favore del fatto che ogni cosa sia un oggetto, il che significa che ogni volta che vuoi una funzione devi avvolgerla in una classe non necessaria .

Bene, abbastanza sconclusionato. Il punto che sto cercando di sottolineare è che Mainnon è proprio una classe, ma una funzione e quindi non dovresti fare altro che analizzare gli input, creare altri oggetti e chiamare altri metodi perché è tutto ciò che una funzione può fare.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.