Un meilleur design? Même objet, différents états possibles

Question

J'ai une application très simple qui consiste en un site frontal ASP.NET, avec un service Windows WCF exécutant la logique principale du back-end.

L'utilisateur a une page simple où il sélectionne certains paramètres et appuie sur un bouton "soumettre". La page appelle le service WCF et lui transmet les paramètres. Le service instanciait une instance d'une classe 'Job', envoyait les paramètres au constructeur, puis appelait une méthode 'Run ()' qui effectue tout le travail consistant à - insérer un enregistrement 'job' dans une base de données avec le nom d'utilisateur, l'heure started, etc ... Effectue une demande auprès d'un fournisseur tiers, récupère les données, les place dans la base de données, effectue une autre logique métier, puis marque le travail comme terminé.

L'utilisateur dispose alors d'une seconde page simple dans laquelle il peut maintenant rechercher son travail (une liste déroulante interrogeable triée par date et affichant plusieurs champs relatifs à ce travail), puis afficher les données correspondant à ce travail à l'écran - ( la plupart des champs de la table des tâches, par exemple heure de début, heure de fin, état, etc. affichés sous forme d'étiquettes dans un panneau) et les données réelles extraites du fournisseur tiers (restituées sous forme de grille, sous le panneau).

Maintenant, passons à ma question - j'ai donc une classe Job qui contient tous les champs mentionnés ci-dessus, ainsi que sa méthode publique Run () et ses constructeurs. Il a quelques fonctions privées simples, et plusieurs membres privés qui sont des interfaces vers des classes telles que IParser, IVendorConnection, IDataAccess - les classes qui effectuent tout le travail décrit ci-dessus. La classe Job et la méthode Run () ne font pas grand chose. le travail réel, à peu près juste des délégués travaillant sur ses objets composites (permet entre autres une bonne testabilité).

Maintenant, cette classe de travail a 3 utilisations / états possibles. Son utilisation principale est à l’intérieur du Service, pour l’utilisation de la fonction Run () afin d’exécuter littéralement un travail. Il a également 2 autres utilisations - agissant en tant que modèle pour le panneau que j'ai décrit ci-dessus et en tant que modèle pour la liste déroulante que j'ai décrite ci-dessus. La classe de travail a 3 constructeurs publics, chacun l’établissant pour l’un des 3 états. Dans tous les cas, chaque «État» ne se soucie que de certains membres que les 2 autres États ne se soucient pas - dans certains cas, certains membres sont utilisés dans les 3 États. Le «statut de la liste déroulante» est le plus simple - dans ce cas, je ne veux que 3 champs en lecture seule. Dans l'état "panneau", je me soucie de 6 champs en lecture seule. Dans l'état "travail", je crée ces valeurs de champ au fur et à mesure que le travail avance - et elles doivent toutes être privées.

Je cherche simplement un moyen plus propre de faire cela. Si j'instancie une classe de travaux dans l'état A, je sais que l'accès au membre X ne fonctionnera pas ou que l'appel de la fonction Y échouera. Cependant, il reste du code compilable.

Je suis sûr que d’autres ont déjà rencontré ce problème. Je pensais avoir une classe Job de base marquée MustInherit / abstract, puis 3 classes dérivées, une pour chaque état. Mettez les membres partagés dans la base et ceux spécifiques à l'état dans les dérivés, et utilisez simplement les classes dérivées dans mon code, le cas échéant. Cela semble assez simple pour mes objectifs et résout mon problème. Peut-être que je pourrais aussi avoir une sorte de JobFactory ... Je suppose que je cherche juste comment les autres personnes ont résolu ce problème, peut-être que je ne pense pas assez en dehors de la boîte ... J'ai déjà eu beaucoup de cours comme des machines à états dans ma les jours de développement de jeux pour les amateurs - mais c'était différent, parce que des instances de ces classes pouvaient changer d'états (par exemple, une classe "Enemy" pouvait avoir son état changé de "attack_mode" à "wait") une fois créé, un travail doit rester dans son état et ne jamais essayer de se comporter dans un autre. Suivre l'état et lancer des exceptions si une méthode / un membre est utilisé alors qu'il ne se trouve pas dans un état donné semble fragile et demande trop de travail. Des suggestions basées sur la façon dont vous avez résolu ce problème auparavant? Et est ce que j'essaye de faire exagéré? Si Job commençait à avoir de plus en plus d'états différents, je pense que non - mais peut-être que s'il en avait autant, je dois penser à le diviser en différentes classes de toute façon ... Cherchez simplement vos 2 centimes.

Answer 1

Votre idée de créer un travail de classe de base unique avec 3 classes dérivées semble exactement comme ce que je ferais aussi. La création d'une JabFactory pourrait aider davantage cette conception. La création d'un objet là où des parties de celui-ci ne sont pas utilisées ou l'utilisation illégale dans certaines circonstances peut être une mauvaise pratique. Donc, créer les classes dérivées avec seulement les parties nécessaires est clairement la meilleure conception. Ce n'est pas exagéré.