c++ - que - ¿Qué entra en la función principal?

que poner en un curriculum sin experiencia

Question

Estoy buscando un consejo sobre las mejores prácticas de lo que se incluye en la función principal de un programa que utiliza c ++. Actualmente creo que dos enfoques son posibles. (Aunque los "márgenes" de esos enfoques pueden estar arbitrariamente cerca uno del otro)

1: Escriba una clase "Master" que reciba los parámetros pasados ​​a la función principal y maneje el programa completo en esa clase "Master" (Por supuesto, también hace uso de otras clases). Por lo tanto, la función principal se reduciría a un mínimo de líneas.

#include "MasterClass.h"
int main(int args, char* argv[])
{
MasterClass MC(args, argv);
}

2: ¡Escriba el programa "completo" en la función principal haciendo uso de objetos definidos por el usuario, por supuesto! Sin embargo, también hay funciones globales involucradas y la función principal puede ser algo grande.

Estoy buscando algunas pautas generales sobre cómo escribir la función principal de un programa en c ++. Me encontré con este problema al intentar escribir una prueba de unidad para el primer enfoque, lo cual es un poco difícil ya que la mayoría de los métodos son privados.

Answer 1

¿Por qué tendrías una clase magistral? ¿Cuál es su única área de responsabilidad?

Las clases "maestras" o "de aplicación" tienden a convertirse en grandes manchas que hacen demasiadas cosas diferentes. En última instancia, ¿cuál es el punto? ¿Qué te compró?

¿Por qué no usar la función principal para proporcionar esta funcionalidad principal ? Defina el ciclo de vida de la aplicación de alto nivel en main . Toma algunos argumentos de la línea de comandos y los analiza (preferiblemente delegándolos a otra función o clase), y luego llama a algunas funciones de configuración, y luego puede ingresar algún tipo de bucle principal, antes de realizar una limpieza. Con todo, esto podría darle una función principal de quizás 10-15 líneas, pero probablemente no más que eso. Debe delegar a otras clases y funciones tanto como sea posible. tan main sí se mantiene corto y dulce, pero todavía tiene un propósito.

Poner este tipo de flujo de súper alto nivel en main significa que es fácil de encontrar, porque main es tu punto de partida de todos modos. Es donde empezarás a buscar si quieres entender el código. Así que ponga en él lo que un lector quiere saber cuando trata de entender el código.

Claro, puedes tomar todo eso y ponerlo en una "clase principal", y no habrás ganado absolutamente nada, aparte de satisfacer a todos los luditas de Java que sienten que "todo debe estar en una clase".

Answer 2

El ejemplo que has dado simplemente mueve la función principal dentro de un espacio de nombres. No veo la ventaja aquí. Me funciona un enfoque en la mitad de la carretera con una ligera tendencia hacia el modelo de Master Class. El objeto de la clase maestra por lo general sería enorme y se crearía mejor en el montón. Tengo la función principal de crear el objeto y manejar cualquier error que pueda ocurrir aquí.

class MasterClass {
public:
static MasterClass* CreateInstance( int argc, char **argv );
    // ...
}

int main(int argc, char** argv)
{
    try
    {
         MasterClass mc = MC::CreateInstance(argc, argv);
    }
    catch(...)
    {
        // ...
    }
}

Esto también tiene la ventaja de que cualquier procesamiento que no tenga nada que ver con la lógica del programa real, como leer el entorno, etc., no tiene que incluirse en la MasterClass. Pueden ir en main (). Un buen ejemplo es una tarea de complemento de servidor para el sistema Lotus Domino. Aquí, la tarea solo debe ejecutarse cuando el control lo entrega la tarea del programador de Domino. Aquí el principal probablemente se verá como a continuación:

STATUS LNPUBLIC AddInMain(HMODULE hModule, int argc, char far *argv[])
{
     MasterClass mc = MC::CreateInstance(argc, argv);
     while(/* wait for scheduler to give control */)
     {
          STATUS s = mc->RunForTimeSlice();
          if (s != SUCCESS)
               break;
     }
     // clean up
}

Toda la lógica para interactuar con el programador está, por lo tanto, en main y el resto del programa no tiene que manejar nada de eso.

Answer 3

Haría el análisis de los argumentos del proceso en la rutina principal, luego crearía una instancia de clase pasando parámetros más legibles que argc y argv.

Answer 4

Normalmente, realizo la acción de configuración necesaria específica de la plataforma y luego delego en un objeto. Hay pocas ventajas de un objeto sobre una función, pero los objetos pueden heredar de las interfaces, lo que es bueno si tiene bibliotecas independientes de la plataforma que usan la implementación de la interfaz para las devoluciones de llamada.

Answer 5

Por lo general, llamo una función principal (con la misma firma) en el espacio de nombres de mi aplicación:

namespace current_application {
    int main( int argc, char **argv ) {
        // ...
    }
}
int main( int argc, char **argv ) {
    return current_application::main( argc, argv );
}

Y luego normalmente uso mi principal real (el que está en el espacio de nombres) para inicializar las cosas de la aplicación :

• establecer locales en entrada / salida / error estándar)

• parámetros de aplicación de análisis

• instanciar el objeto de mi clase principal, si está presente (el equivalente a algo como QApplication )

• llamar a la función principal, si está presente (el equivalente de algo como QApplication::run )

y, por lo general, prefieren agregar un bloque try catch allí para imprimir más información de depuración en caso de fallo.

Todo esto es altamente subjetivo, sin embargo; Es parte de tu estilo de codificación.

Answer 6

Prefiero un enfoque IOC (Inversión de control) para mis programas.

Mi "principal" por lo tanto usa los argumentos de comando para determinar las "opciones" y la "configuración" del programa. Por opciones me refiero a interpretar ciertos indicadores pasados ​​en la línea de comandos y por configuración me refiero a cargar archivos de configuración.

El objeto que utiliza para cargar los archivos de configuración tiene un comando para "ejecutar", pero lo que se ejecuta (si corresponde) depende también de los argumentos de la línea de comandos.

Answer 7

Primero: Raramente uso C ++, pero asumo que esto no es realmente un problema específico del idioma.
Bueno, supongo que esto se reduce a probar, aparte de algunos problemas prácticos. Personalmente tiendo a usar el diseño n. ° 1, pero no coloque las rutinas de análisis de la línea de comandos en MasterClass . Para mí, eso claramente pertenece a lo principal. La MasterClass debería obtener los argumentos analizados (enteros, FileStreams, lo que sea).

Answer 8

Si una excepción no tiene un controlador, no se especifica si se llama a los destructores de objetos locales antes de std::terminate .

Si desea que ese comportamiento sea predecible, main es un buen lugar para tener un controlador de excepciones superior, con algún tipo de informe.

Por lo general, eso es todo lo que pongo en main , que de otro modo solo llama a cppMain ... ;-)

Salud y salud,

Answer 9

Tu primer acercamiento es muy común, aunque la clase tiende a llamarse ''Aplicación'' (o al menos contiene la palabra ''Aplicación''), así que hazlo.

Answer 10

Usted está describiendo dos enfoques "extremos", ninguno de los cuales me parece correcto. Ni tener una sola Clase de Dios , ni tener una sola Función de Dios es la manera correcta de implementar cualquier programa no trivial destinado para un uso real.

Puede estar bien tener una sola llamada a MasterClass dentro de main() (aunque preferiría una mejor funcionalidad de partición, por ejemplo, realizar cualquier procesamiento específico de la línea de comandos en main() , para desacoplar MasterClass de los detalles de los parámetros de la línea de comandos). Sin embargo, si esa clase es difícil de probar por unidades, es un signo de un problema de diseño y, por lo general, la solución es delegar parte o toda su funcionalidad comprobable a otras clases en las que se puede probar fácilmente en forma separada por medio de interfaces públicas. .

Su segundo enfoque puede volver a ser problemático para la prueba de unidad, por lo que debe esforzarse por extraer métodos de la misma (y luego, preferiblemente, moverlos a una clase separada ) para hacer posibles las pruebas de unidad de grano fino.

El punto dulce en el que desea estar está, por lo tanto, en algún lugar entre los dos extremos, limitado por el requisito de hacer que su código sea verificable.

Vale la pena pensar en cómo estructurar sus programas en general, no solo en el contexto de main() . La idea básica es dividirla en "trozos" (clases y métodos) que son

• Lo suficientemente pequeño como para ser comprendido, probado y mantenido fácilmente.
• lógicamente cohesivo.