¿El método principal debería consistir solo en creaciones de objetos y llamadas a métodos?


12

Un amigo mío me dijo que, la mejor práctica es que el mainmétodo que contiene la clase debe nombrarse Mainy solo contiene el mainmétodo. Además, el mainmétodo solo debe analizar entradas, crear otros objetos y llamar a otros métodos. La Mainclase y el mainmétodo no deberían hacer nada más. Básicamente, lo que está diciendo es que el mainmétodo que contiene la clase debería ser:

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

¿Es la mejor práctica?


66
¿Qué más puede hacer?
Pubby

Respuestas:


11

El punto que su amigo está haciendo es que una aplicación simplemente debe ser arrancada por el método principal, y nada más. Al tener el método principal en su propia clase, simplemente está reforzando ese hecho al mantenerlo independiente de cualquier lógica de aplicación. La función del método principal sería analizar cualquier entrada e inicializar la aplicación con esas y posiblemente otras entradas.

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

La idea es que no necesita el método principal para inicializar Foo. Esto le permite inicializar fácilmente y comenzar Fooen otro contexto, potencialmente con una semántica diferente.

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

7

El método main () es un retroceso feo a la programación de procedimientos, que proporciona el punto de entrada a la aplicación. Se hacen intentos en varios lenguajes de programación para encapsularlo, pero su propia naturaleza lo hace difícil (tiene que ser público y estático, pero NUNCA debe llamarse desde otra parte del programa, lo cual es muy contradictorio). WPF tuvo éxito (al ocultar main () de usted profundamente en las entrañas del proyecto de la aplicación WPF y proporcionar "ganchos" configurables para el procesamiento personalizado), al igual que Java (de manera similar para las aplicaciones de Android), pero WinForms y la mayoría de los otros tipos de las aplicaciones aún te hacen lidiar con main ().

Entonces, la mayoría de los expertos dicen que el LOC de la función main () debería ser lo más bajo posible. Hay un enfoque (que creo que es un poco exagerado) en el que la función main () tiene una línea:

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

Esto es un poco demasiado, pero estoy de acuerdo con el principio básico; main () debe hacer lo menos posible para que su aplicación orientada a objetos y orientada a eventos esté en un estado "listo".


Estoy en desacuerdo. Puede ser útil llamar maindesde otros contextos, por ejemplo, recursividad.
DeadMG

44
Personalmente, si recurres a tu método principal, creo que deberías llamar a otro método y repetirlo. Solo en los contextos más simples (aplicación de consola de complejidad / dificultad aproximadamente a nivel de tarea) sería aceptable llamar a main () desde su programa, y ​​yo llamaría a eso una situación trivial.
KeithS

1

En los idiomas que admiten funciones maines solo una función regular y, por lo tanto, no hay nada más que pueda hacer con ella que no sea lo que dijo. Y luego hay lenguajes idiotas que abandonan las funciones a favor de que todo sea un objeto, lo que significa que cada vez que quieres una función tienes que envolverla en una clase innecesaria .

Bueno, basta de divagaciones. El punto que estoy tratando de hacer es que Mainno es realmente una clase, sino una función, por lo que no debería haber hecho nada más que analizar entradas, crear otros objetos y llamar a otros métodos porque eso es todo lo que una función puede hacer.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.