Conception de haut niveau pour l'application d'installation et de mise à niveau

Question

Je dois écrire une application WinForms très simple, mais je reste souvent bloqué en mode analytique avec ces applications. Je reste bloqué sur les boucles Oui, Non, Réessayer, et avec très peu de réflexion sur les actions de l'application, je commence à penser au «flux de travail» de l'application. Devrais-je simplement avoir une méthode pour chaque tâche et appeler chacune d'elle séquentiellement, après avoir vérifié que la précédente n'a pas déclenché l'indicateur d'abandon?

Devrais-je implémenter une interface ITask simple et une classe pour chaque tâche, puis parcourir en boucle une collection ordonnée de tâches? Devrais-je utiliser cela comme une simple introduction à Windows Workflow? La portée de cette application et de son ensemble de tâches est garantie, donc ma première option de codage en dur des tâches est la plus méchante, mais étant donné la taille de l'application, la maintenance peut être facilement effectuée en modifiant simplement le code; l'exécutable est toujours déployé avec les matériaux de mise à niveau et n'est pas déployé de manière permanente.

Answer 1

Sur la base du flux de travail, je le garderais pour les scénarios / projets avancés, où vous en utiliserez beaucoup, comme un flux de travail hautement personnalisable que vous souhaitez modifier par utilisateur / société, des besoins de flux de travail complexes, mettez en pause / continuez.

Je choisirais la voie ITask pour sa flexibilité (par rapport aux méthodes simples), tout en restant simple en même temps. Je pense que cela vous aidera également avec les tests unitaires / d'intégration. Cela dit, je vous recommande de garder un œil sur la réutilisation des tâches, comme par exemple une tâche de déplacement de fichier, car vous ne voulez pas terminer avec des tonnes de tâches qui font de même. Faites-le simplement sur les étapes de refactoring, de sorte que vous laissiez les besoins / utilisations réels dicter ce dont vous avez besoin (dans les tests - TDD:)).

Answer 2

Faites la chose la plus simple. Vous pouvez toujours refactoriser plus tard.

Answer 3

Je vais ajouter à la suggestion de Peter en disant: "Faites la chose la plus simple qui soit pourrait faire: c'est aussi une bonne conception ".

Il arrive que le "plus simple" " La chose est aussi la chose la plus stupide, du point de vue de la conception, et elle causera des problèmes plus tard, ce qui est le contraire de ce que le mantra de la programmation extrême (Extremem Programming) poursuit.

Votre deuxième option me semble juste. Il est simple à mettre en œuvre, de bonne conception et facilitera la maintenance ultérieurement.