Comment écrire main () de manière POO?

Question

Quand j'ai commencé à programmer, j'ai tout écrit dans main. Mais comme j'ai appris, j'ai essayé de faire le moins possible avec mes méthodes main () .

Mais où décidez-vous de donner à l'autre classe / méthode la responsabilité de reprendre le programme depuis main () ? Comment faites-vous cela?

J'ai vu plusieurs façons de le faire, comme ceci:

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

et certains aiment:

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'est-ce qui devrait et ne devrait pas être fait dans main () ? Ou n'y a-t-il pas de balles d'argent?

Merci pour le temps!

Answer 1

À mon avis, le "principal" d’un projet important doit contenir environ 3 appels de fonction:

• Appel d'une fonction d'initialisation qui configure tous les paramètres, préférences, etc. requis pour l'application.
• Démarrage du & contrôleur principal " de l'application
• Attente de la fin du contrôleur principal, puis appel d'une fonction de terminaison qui nettoie tout ce qui doit être nettoyé dans le menu "principal". (bien que le contrôleur se soit déjà occupé de l'essentiel du nettoyage).

Toute application volumineuse sera divisée en blocs de fonctionnalités, généralement avec une hiérarchie. Le contrôleur principal peut avoir plusieurs contrôleurs enfants pour des fonctionnalités spécifiques.

En procédant ainsi, il est beaucoup plus facile de localiser des fonctionnalités spécifiques et la séparation des préoccupations est préférable.

Bien sûr, comme d’autres réponses l’ont dit, il n’ya vraiment pas de solution miracle au développement logiciel. Pour un projet de courte durée, je pourrais tout mettre en œuvre pour que tout soit opérationnel rapidement. Je pense aussi que cela dépend de la langue - certaines options peuvent être plus faciles que d’autres dans des langues particulières.

Answer 2

Code dans la fonction principale:

• Ne peut pas être testé par unité.
• Impossible de recevoir des dépendances par injection.
• Ne peut pas être réutilisé par d'autres applications similaires à la première que vous écrivez.

Par conséquent, code dans la fonction principale:

• Doit être si simple que vous êtes satisfait des tests de fonctionnement / du système uniquement.
• Doit être responsable de la mise en marche des dépendances utilisées par tous vos autres codes (c'est-à-dire que Main agit comme une super-usine qui crée votre application).
• Ne devez faire que des tâches particulières à la manière dont votre application est configurée (c’est-à-dire que le code de test ou la version de démonstration n’auront pas à fonctionner exactement de la même manière).

En pratique, cela signifie que les applications réelles n’ont pas grand-chose en principal. Les applications pour jouets et les programmes à action unique peuvent avoir beaucoup de problèmes, car vous n’avez pas l’intention de les tester ou de les réutiliser de toute façon.

En fait, une partie de ce que je dis ci-dessus est spécifique à C ++. Les principales méthodes Java peuvent bien sûr être appelées par code de test ou par variantes. Mais ils ne prennent toujours pas les objets en tant que paramètres, mais uniquement des arguments de ligne de commande. Par conséquent, leur capacité à être isolés sous test ou à se comporter correctement en termes de réutilisation est assez faible. Je suppose que vous pouvez leur attribuer des noms de classe et les utiliser pour créer le reste de l’application.

[Modifier: une personne a supprimé le " C ++, Java " balises de cette question. Donc: ce que je dis ci-dessus est spécifique à C ++ et à Java. D’autres langues peuvent traiter le principal de manière moins spéciale, auquel cas il n’ya aucune raison particulière de le traiter spécialement.]

Answer 3

Tout ce qui flotte sur votre bateau, comme on dit. :) Vous devez vraiment vous concentrer sur la simplification, la lisibilité et l'efficacité du code, en utilisant les outils nécessaires pour y parvenir. Si cela justifie de mettre beaucoup de code dans le système principal, faites-le. Si vous pensez que les objets rendraient les choses plus organisées, suivez ce chemin.

Créer une instance unique de la classe Main , puis appeler la méthode d'instance Main () , qui effectue tout le travail, vaut tout aussi bien que de tout écrire directement dans la méthode principale .

Answer 4

Je dirais que ce n’est pas ce qui est dans votre fonction principale, mais ce qui ne l’est pas. Selon la complexité de votre projet, vous souhaiterez le scinder en sections fonctionnelles, telles que "Fonctions de base de données", "Fonctions d'affichage", "High Tea with the Vicar", etc.

Tout est une question de lisibilité du code. Quelqu'un d'autre, qui n'a jamais vu votre programme auparavant, peut-il en avoir une bonne idée générale de ce qu'il fait?

Vous pouvez alors voir facilement où aller pour creuser un peu plus profondément dans le mécanisme?

Chaque section fonctionnelle utilisée utilise-t-elle uniquement un bloc logique de processus? Il n’est pas nécessaire de faire une seule chose, mais cela ne devrait pas être tout plus l’évier de la cuisine.

Décomposez votre code de manière à ce qu'il soit maintenable par une source externe.

Parce que Dieu sait, quand il le faut, si quelqu'un d'autre peut réparer le bogue, c'est tant mieux =)

En réponse directe à votre question, je mettrais les appels de fonction à chacun des composants principaux du système, à la configuration, au processus et à la finition, de manière à ce que tous ceux qui le consulteraient obtiennent un aperçu rapide du fonctionnement du programme. travaux. Ils peuvent ensuite approfondir leurs recherches si besoin est.

Answer 5

Regardez, le contenu et la forme de la " main " La méthode est très dépendante de la langue et de l’environnement. En Java, chaque classe peut avoir une méthode publique statique void main () . Il est donc tout à fait possible d’en avoir plusieurs.

Mais maintenant, réfléchissons à cela via la loi de modularisation de Parnas: "chaque module cache un secret, et ce secret est quelque chose qui peut changer." Le " secret " Le module appelé initialement contient les détails de l’interfaçage du processus avec le système d’exploitation, comme obtenir les arguments et gérer les terminaisons irrégulières. En Python, cela conduit à quelque chose comme ceci:

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

Le point ici est que vous obtenez tout de l'environnement que vous pouvez, puis appelez la fonction main (); vous attrapez toutes les exceptions non capturées et vous faites quelque chose d'intelligent avec elles avant la mort du programme.

Answer 6

Je pense que la méthode principale devrait expliquer ce que le programme fait au démarrage. On peut donc appeler des méthodes initialzing, mais la logique doit être extraite en méthodes.

Dans votre exemple, je ne créerais pas de méthode Main (), mais la mettrais dans la méthode d'origine.

Answer 7

La conception de votre programme déterminera la forme de votre "principal".

Avoir une " règle " cela dit comment votre fonction principale devrait être, est - IMHO - un non-sens.

Answer 8

N'oubliez pas que si quelqu'un veut avoir une idée du fonctionnement de votre programme, le premier endroit où il se tournera sera probablement dans la position principale (du moins je le ferais). Donc, je ne pense pas que ce soit une bonne idée de mettre le moins possible. Mais je dirais de mettre le moins possible pour avoir une vue d'ensemble du fonctionnement de votre programme.

Par conséquent, je pense que votre principale préoccupation lors de la mise en œuvre d'une fonction principale devrait être la lisibilité.