Pregunta

Cuando comencé a programar, escribí todo en main. Pero como aprendí, traté de hacer lo menos posible en mis métodos main () .

Pero, ¿dónde decide darle a la otra Clase / Método la responsabilidad de hacerse cargo del programa de main () ? ¿Cómo lo haces?

He visto muchas formas de hacerlo, así:

class Main
{
  public static void main(String[] args)
  {
    new Main();
  }
}

y algunos como:

class Main {

   public static void main(String[] args) {

    GetOpt.parse(args);

    // Decide what to do based on the arguments passed
    Database.initialize();
    MyAwesomeLogicManager.initialize();
    // And main waits for all others to end or shutdown signal to kill all threads.
  }
}

¿Qué debe y no debe hacerse en main () ? ¿O no hay balas de plata?

¡Gracias por el tiempo!

¿Fue útil?

Solución

En mi opinión, el " principal " de un proyecto considerable debe contener alrededor de 3 llamadas a funciones:

  • Llamar a una función de Inicialización que configura todos los ajustes, preferencias, etc. necesarios para la aplicación.
  • Inicio del controlador principal "" de la aplicación
  • Esperando a que termine el controlador principal y luego llamando a una función de Terminación que limpia todo lo que necesita limpiarse en " main " (aunque el controlador ya se habrá hecho cargo de la mayor parte de la limpieza).

Cualquier aplicación considerable se dividirá en fragmentos de funcionalidad, generalmente con cierta jerarquía. El controlador principal puede tener varios controladores secundarios para funciones específicas.

Hacerlo de esta manera hace que sea mucho más fácil localizar una funcionalidad específica, y la separación de preocupaciones es mejor.

Por supuesto, como han dicho otras respuestas, realmente no hay una bala de plata en el desarrollo de software. Para un proyecto corto, podría poner todo en main solo para poner las cosas en marcha rápidamente. Creo que también depende del idioma: algunas opciones pueden ser más fáciles que otras en determinados idiomas.

Otros consejos

Código en la función principal:

  • No se puede probar por unidad.
  • No se pueden recibir dependencias por inyección.
  • No puede ser reutilizado por otras aplicaciones similares a la primera que escribes.

Por lo tanto, codifique en la función principal:

  • Debe ser tan simple que solo esté satisfecho con las pruebas funcionales / del sistema.
  • Debe ser responsable de poner en marcha las dependencias utilizadas por todos los demás códigos (es decir, los actos principales como una súper fábrica que crea su aplicación).
  • Solo debe hacer cosas que sean particulares de la forma en que está configurada su aplicación (es decir, nada que el código de prueba o la versión de demostración deba hacer exactamente de la misma manera).

En la práctica, esto significa que las aplicaciones reales no tienen mucho en main. Las aplicaciones de juguete y los programas de una sola vez pueden tener bastante en main, porque no estás planeando probarlos o reutilizarlos de todos modos.

En realidad, algo de lo que digo arriba es específico de C ++. Los principales métodos de Java, por supuesto, se pueden invocar mediante código de prueba o aplicaciones variantes. Pero todavía no toman los objetos como parámetros, solo argumentos de línea de comandos, por lo que el grado en que pueden aislarse bajo prueba o comportarse bien en términos de reutilización es bastante bajo. Supongo que podría pasar los nombres de clase para que puedan crear instancias y usar para crear el resto de la aplicación.

[Editar: alguien ha eliminado el " C ++, Java " Etiquetas de esta pregunta. Entonces: lo que digo arriba es C ++ y Java específico. Otros idiomas pueden tratar main de una manera que es menos especial, en cuyo caso tampoco puede haber una razón particular para que lo trates especialmente.]

Lo que sea que haga flotar tu bote, como dicen. :) Realmente deberías enfocarte en hacer que el código sea simple, fácil de leer y eficiente, usando cualquier herramienta que necesites para lograr esto. Si garantiza poner mucho código en main, hágalo. Si crees que los objetos harían las cosas más organizadas, ve por ese camino.

Hacer una sola instancia de class Main y luego llamar al método de instancia Main () que hace todo el trabajo es tan bueno como escribir todo en el método principal directamente .

Diría que no es lo que está en su función principal, sino lo que no. Dependiendo de la complejidad de su proyecto, deseará dividirlo en secciones funcionales, como "Funciones de base de datos", "Funciones de visualización", "High Tea with the Vicar", etc.

Se trata de la legibilidad del código. ¿Puede alguien más, que nunca antes ha visto su programa, encontrarlo y obtener al principio una buena idea general de lo que hace?

¿Entonces puede ver fácilmente a dónde ir para profundizar un poco más en el mecanismo?

¿Cada sección funcional que usa hace solo un bloque lógico de procesos? No solo tiene que hacer una cosa, sino que no debería estar haciendo todo más el fregadero de la cocina.

Descomponga su código de manera que pueda ser mantenido por una fuente externa.

Porque los cielos lo saben, cuando se trata de eso, si alguien, por sí solo, puede solucionar el error, es mucho mejor =)

Como respuesta directa a su pregunta, pondría las llamadas de función a cada uno de los componentes principales en main, la configuración, el proceso y el final, para que cualquiera que lo vea obtenga una visión general rápida de cómo funciona el programa trabajos. Luego pueden profundizar más si es necesario.

Mire, el contenido y la forma del " main " El método depende mucho del idioma y del entorno. En Java, cada clase puede tener un método public static void main () , por lo que es completamente factible tener más de uno.

Pero ahora, pensemos en esto a través de la ley de modularización de parnas: "cada módulo oculta un secreto, y ese secreto es algo que puede cambiar". El "secreto" del módulo que se llama inicialmente son los detalles de la interfaz del proceso con el sistema operativo: cosas como obtener los argumentos y manejar terminaciones irregulares. En Python, esto lleva a algo como esto:

def main(args=None):
    #argument processing
    #construct instances of your top level objects
    #do stuff

if __name__ == "__main__":
   try:
      main(Sys.Argv)
   except: # everything
      # clean up as much as you can
   else:
      # normal cleanup, no exceptions

El punto aquí es que obtienes todo del entorno que puedes, luego llama a la función main (); Capturas todas las excepciones no detectadas y haces algo inteligente con ellas antes de que el programa muera.

Creo que el método principal debería explicar qué hace el programa al iniciarse. Por lo tanto, puede llamar métodos de inicialización, pero la lógica debe extraerse en métodos.

En su ejemplo, no crearía un método Main (), sino que lo pondría en el original.

El diseño de su programa decidirá la forma de su " principal " ;.

Tener una " regla " eso dice cómo debería ser su función principal, es - en mi humilde opinión - un sin sentido.

Recuerda que si alguien quiere tener una idea de cómo funciona tu programa, el primer lugar en el que probablemente se verán es principal (al menos yo lo haría). Por lo tanto, no creo que sea una buena idea poner lo menos posible. Pero diría que ponga tan poco como sea necesario para obtener una vista panorámica de cómo funciona su programa.

Por lo tanto, creo que su mayor preocupación en la implementación de una función principal debería ser la legibilidad.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top