sirve showmessagedialog showinputdialog que programacion personalizar para mostrar mensaje libro error ejemplos desde cero java coding-style

showmessagedialog - Método principal de Java, buen estilo de codificación



personalizar joptionpane (6)

Estoy de acuerdo con tu 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.

He tenido una discusión bastante larga con un amigo sobre el uso correcto y bueno del método principal en Java. Básicamente tenemos una clase como esta:

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

¿Pero dónde poner el método principal? Considero que es una buena práctica "mantener el código donde corresponde", convirtiendo 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 que mi amigo argumenta que "el código de inicio no tiene nada que ver con la aplicación en sí", por lo tanto, debe colocarse en otra clase, como esta:

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 discutimos el asunto durante algún tiempo, ambos terminamos sin una conclusión sobre de qué manera 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?


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

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

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


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. En general tendré 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(); } } }

Simplemente se siente más limpio.


Probablemente iría con tu 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 describes)

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 que lo abarca) CUANTO ANTES. Pero ey ... eso solo soy yo;)


Siempre separo el principal del resto del código, por varias razones:

1) Un main es, en cierto modo, un hack para que su programa comience desde la línea 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) Podría terminar teniendo múltiples fuentes (por ejemplo, con ciertos parámetros predeterminados, con modos especiales, etc.)

3) Podría terminar ejecutando el programa desde un entorno diferente (por ejemplo, un plugin de Eclipse o un módulo de 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 tu 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 deseas que el resto del código esté en el paquete predeterminado.


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?