2009-04-08 17 views
35

He tenido una larga discusión con un amigo sobre el uso correcto y correcto del método principal en Java. Básicamente tenemos una clase como esta:Método principal de Java, buen estilo de codificación

public class AnImporter implements Runnable { 
    // some methods, attributes, etc. 
} 

Pero, ¿dónde poner el método principal? Me concider es una buena práctica para "mantener el código que le corresponde", convirtiendo así el código anterior en

public class AnImporter implements Runnable { 
    public static void main(String [] args){ 
    // Startup code for Importer App here 
    } 
    // some methods, attributes, etc. 
} 

Mientras mi amigo sostiene que "el código de inicio no tiene nada que ver con la aplicación en sí", por lo que debe ser colocado en otra clase, así:

public class AnImporter implements Runnable { 
    // some methods, attributes, etc. 
} 

public class AnApplication { 
    // Nothing here 
    public static void main(String [] args){ 
    AnImporter a = new AnImporter(); 
    // Startup code here 
    } 
    // Nothing here 
} 

a pesar del hecho de que hemos discutido el asunto desde hace algún tiempo que ambos terminamos con ninguna conclusión sobre qué camino es el mejor enfoque en Java. ¿Cuál es su opinión sobre este tema? ¿Dónde y lo más importante, por qué, colocas tu método principal donde lo colocaste?

+0

necesita preguntarse: ¿por qué (o por qué no) pertenece el método principal en esa clase? –

Respuesta

35

Estoy de acuerdo con su amigo. Está creando un servicio potencialmente reutilizable en AnImporter que podría usarse potencialmente en múltiples programas con múltiples main's. Por lo tanto, hacer una especial principal e incrustarla en AnImporter no tiene mucho sentido.

11

No contaminaría una clase Runnable con un método principal. Lo mismo aplica para casi cualquier clase que haga algo en su aplicación. Por lo general voy a tener una clase como esta:

public class App { 
    public static void main(String args[]) { 
    Thread t = new Thread(new Blah()); 
    t.start(); 
     synchronized (t) { 
     t.wait(); 
     } 
    } 
} 

public class Blah implements Runnable { 
    public void run() { 
    // do normal stuff 
    } 
} 

en lugar de:

public class Blah implements Runnable { 
    public void run() { 
    // do normal stuff 
    } 

    public static void main(String args[]) { 
    Thread t = new Thread(new Blah()); 
    t.start(); 
    synchronized (t) { 
     t.wait(); 
    } 
    } 
} 

Se siente más limpio.

14

Probablemente vaya con su amigo, ya que preferiría salir de la clase con el método principal lo más rápido posible. Ayuda a facilitar las pruebas cuando se quiere evaluar atómicamente (solo la clase ejecutable) o si se quiere burlar las cosas. Cuanto antes salga del método principal, más opciones tendrá. Si tiene una clase con el método principal y otras cosas en ella, podría desordenarse rápidamente. (incluso si no parece ser así con un ejemplo simple como el que describe)

Pero yo diría que la legibilidad y la capacidad de prueba son dos buenas razones para salir del método principal (y su clase abarcadora) CUANTO ANTES . Pero hey..that es sólo conmigo;)

+1

Sí. También saldría de Applet/JApplet lo antes posible. –

7

siempre que separan la principal desde el resto del código, por varias razones:

1) Un principal es, en cierto modo, un truco para dejar que su programa de inicio desde la linea de comando Cualquier clase que lo contenga debe tener una sola responsabilidad: dejar que el programa comience desde la línea de comando. Al ponerlo con su principal ejecutable, está contaminando el ejecutable.

2) Se podría llegar a tener múltiples de red (por ejemplo, con ciertos parámetros por defecto, con modos especiales, etc.)

3) podría terminar la ejecución del programa a partir de un ambiente diferente (por ejemplo, un Eclipse complemento o módulo OGSI, un applet, una herramienta basada en web, etc.). En esos casos, le conviene restringir el acceso a su principal. Ponerlo con la funcionalidad lo impide.

4) A veces es más fácil dejar su main en el paquete predeterminado para acelerar la ejecución del tiempo de ejecución (p. Ej., Java myblabla par1 par2 par3), pero definitivamente no desea el resto del código en el paquete predeterminado .

+0

+1 para obtener una buena respuesta, pero yo diría que nunca se debe poner ninguna clase en el paquete "predeterminado", ni siquiera el que tiene main. –

+0

He descubierto que los usuarios que no están acostumbrados a Java o que usan herramientas de línea de comandos a menudo prefieren una invocación de estilo C. Están dispuestos a "absorber el JAR", pero es la larga secuencia de paquetes que no les gusta. – Uri

2

La interfaz para main (una lista de cadenas) es aproximadamente inútil, excepto para el shell del sistema operativo.

Su principal debe tener el código más pequeño que sea humanamente posible en él.

De hecho, su public class ThisIsMyApp {...} no debería ser nada más que la interfaz del sistema operativo para el trabajo real, que está en otra parte.

0

Yo separaría el método principal del código.

Aunque también tengo un tipo diferente de proyecto. Incluye no un programa real de trabajo para una solución. Aquí necesito ejecutar diferentes soluciones para diferentes problemas usando (y desarrollando) la misma biblioteca. Diferentes problemas no son paralelos. Necesito ejecutar un solo problema solo desde mi IDE. Me pareció conveniente utilizar el mismo proyecto con una gran cantidad de clases con métodos PSVM.

Este proyecto contiene soluciones de concursos de programación para más de 400 problemas diferentes. ¿Tienes una mejor organización para esto?

Cuestiones relacionadas