Modèle de conception pour un logiciel d'audit de questions/réponses

Question

Je voudrais construire une sorte de logiciel d'enquête/d'audit. Je réfléchis à la façon de construire mes cours et s'il y a un modèle de conception qui pourrait me soutenir. Parce qu'il doit y avoir quelque chose qui rend la vie plus facile ...

Mon application doit contenir des questions qui contiennent un titre et une description. Et puis j'ai plusieurs types de réponses.

Alors ... un type pourrait être un réponse oui/non Un autre type pourrait être une valeur comprise entre 1 et 10. Un autre type pourrait libérer réponse texte Un autre type pourrait être un trois choix de texte données où vous pouvez sélectionner un (Le dîner était excellent, bon, signe de la tête)

Donc, sur le site de planification de l'enquête, j'écrirais mes questions et assignerais les types de réponses.

Et sur l'exécution de l'enquête, je veux marcher comme une collection de questions avec une réponse ...

Fondamentalement, la question est de savoir comment unifier tous les différents types de réponses et comment les stocker dans la base de données?

J'ai regardé modèle composite et de la stratégie mais je ne suis pas sûr ... et je sais qu'il n'y a pas une solution parfaite et il dépend toujours ...

Mais ce serait bien si quelqu'un peut partager les meilleures pratiques sur la façon dont ils dealed avec des sujets similaires ...

Merci à l'avance ...

Answer 1

ce que vous semblez demander ici est ce sont les différentes stratégies de cartographie des entités qui sont à votre disposition dans la base de données? En bref, vous pouvez:

1. une table par entité
2. une table unique pour toutes les entités ayant une valeur discriminante pour identifier chacune (les valeurs pourrait être juste une chaîne sous forme de jeton, par exemple) - essentiellement une grande carte
3. une table par entité avec 1: 1 rejoindre pour des propriétés facultatives

Votre solution ORM lit alors les données en arrière à partir de la base de données et il se transforme en le type d'objet approprié (l'entité) peuplant les champs comme il va .

En termes de niveau intermédiaire, vous aurez besoin des classes suivantes:

AbstractQuestion

Une classe de base abstraite pour les questions. Contenant le titre, la description et les méthodes abstraites ask() et answer(). Il y aura une variété de sous-classes pour AbstractQuestion qui fournissent différents messages d'affichage en fonction du type de question. Par exemple, MultiChoiceQuestion implémentera la méthode ask() de telle sorte que le titre et la description soient affichés (vous pouvez le faire dans la méthode askQ de AbstractQuestion) avec tous les choix disponibles (qui est spécifique à chaque sous-classe) . Cela pourrait être généralisé de sorte que ask() prenne une Map en tant que paramètre qui peut être peuplé avec tout ce que vous voulez. Ou vous pouvez utiliser varargs - peu importe.

Réponse

Juste une classe simple contenant une carte avec des touches connues représentant les différents aspects de la réponse avec une référence à la AbstractQuestion propriétaire.

Questionnaire

Une collection de AbstractQuestions disposées dans une liste. Pour chaque AbstractQuestion appelez la méthode ask(), attendez la saisie de l'utilisateur, puis appelez la méthode answer() avec les données fournies.

Pas besoin de motifs de conception complexes, sauf si vous comptez des classes de base abstraites comme un motif. Ce qui précède n'est pas complet, mais cela devrait suffire pour vous aider à démarrer.