Comment décomposer de grandes classes 'macro'?

Question

Une application sur laquelle je travaille ne fait qu'une chose, en regardant du monde extérieur. Prend un fichier en entrée et après ~ 5 minutes crache un autre fichier. Ce qui se passe à l'intérieur est en réalité une série d'actions séquentielles. L'application est, à notre avis, bien structurée car chaque action est comme une petite boîte, sans trop de dépendances.

Habituellement, certaines actions ultérieures utilisent certaines informations de la précédente et seulement quelques-unes peuvent être exécutées en parallèle - par souci de simplicité, nous préférons l'exécution séquentielle.

Maintenant, le problème est que la fonction qui exécute toutes ces actions est comme un fichier batch: une longue liste d'appels à différentes fonctions avec des arguments différents. Ainsi, en regardant dans le code, il ressemble à:

main 
{ 
    try 
    { 
     result1 = Action1(inputFile); 
     result2 = Action2(inputFile); 
     result3 = Action3(result2.value); 
     result4 = Action4(result1.value, inputFile); 
     ... //You get the idea. There is no pattern passed paramteres 
     resultN = ActionN(parameters); 
     write output 
    } 
    catch 
    { 
     something went wrong, display the error 
    } 
} 

Comment qualifieriez-vous le modèle de la fonction principale de cette application est donc non seulement une longue liste de commandes?

Answer 1

Vous ne savez pas si c'est la meilleure approche, mais vous pourriez avoir un objet qui stockerait tous les résultats et que vous donneriez à chaque méthode à son tour. Chaque méthode lirait les paramètres dont elle a besoin et écrirait son résultat là. Vous pourriez alors avoir une collection d'actions (soit en tant que délégués ou objets implémentant une interface) et les appeler en boucle.

class Results 
{ 
    public int Result1 { get; set; } 
    public string Result2 { get; set; } 
    … 
} 


var actions = new Action<Results>[] { Action1, Action2, … }; 

Results results = new Results(); 

foreach (var action in actions) 
    action(results); 

Answer 2

Tout ne doit pas nécessairement s'adapter à un modèle intelligent. Il y a peu de manières plus élégantes d'exprimer une longue série de déclarations impératives que, bien, une longue série de déclarations impératives.

S'il y a certains types de flexibilité, vous sentez que vous manquez actuellement, exprimez-les, et nous pouvons essayer de proposer des solutions.

Si certains groupes d'actions et résultats sont souvent réutilisés, vous pouvez les extraire dans de nouvelles fonctions et créer des actions "agrégées".

Vous pouvez regarder dans les langages et les bibliothèques de flux de données, mais je m'attends à ce que le gain soit faible.

Answer 3

Vous pouvez penser à mettre en œuvre un flux de travail séquentiel de Windows Workflow

Answer 4

Tout d'abord, cette solution est loin d'être mauvais. Si les actions sont disjointes, je veux dire qu'il n'y a pas de paramètres globaux ou d'autres dépendances cachées entre les différentes actions ou entre les actions et l'environnement, c'est une bonne solution. Facile à maintenir ou à lire, et lorsque vous avez besoin d'étendre la fonctionnalité, il vous suffit d'ajouter de nouvelles actions, lorsque la «quantité» change, vous n'avez plus qu'à ajouter ou supprimer des lignes de la macro-séquence. S'il n'y a pas besoin de changer fréquemment la chaîne de processus: ne bouge pas!

Si c'est un système, où l'implémentation des actions ne change pas souvent, mais oui leur ordre et leurs paramètres, vous pouvez concevoir un langage de script simple et transformer la classe de macros en ce script. Ce script doit être géré par quelqu'un d'autre que vous, quelqu'un qui connaît le domaine du problème au niveau de vos "actions". Ainsi, il/elle peut assembler l'application en utilisant le langage de script sans votre aide.

Une approche intéressante pour ce type de division de problème est la programmation de flux de données (par exemple, la programmation basée sur le débit). Dans la programmation de flux de données, il existe des composants pré-écrits.Les composants sont des boîtes noires (à partir de la vue du développeur de l'application), ils ont des ports consommateur (entrée) et producteur (sortie), qui peuvent être connectés pour former un réseau de traitement, qui est alors l'application. S'il existe un bon ensemble de composants pour un domaine, de nombreuses applications peuvent être créées sans programmation de nouveaux composants. En outre, les composants peuvent être construits avec d'autres composants (ils ont appelé des composants composites).

Wikipedia (bon Point de départ): http://en.wikipedia.org/wiki/Dataflow_programming http://en.wikipedia.org/wiki/Flow-based_programming

site de JPM (livre, wiki, tout): http://jpaulmorrison.com/fbp/

I pense, les plus grands systèmes doivent avoir ce point de partage que vous décrivez comme "macro". Même les jeux ont ce point, par ex. Les jeux FPS ont un moteur 3D et un script de logique de jeu, ou SCUMM VM, qui est la même.