Comment créer une interface graphique pour une classe polymorphe?

Disons que j'ai un générateur de tests, pour que les enseignants puissent créer un tas de questions pour un test.

Cependant, toutes les questions ne sont pas identiques: vous avez plusieurs choix, zone de texte, correspondance, etc. Chacun de ces types de questions doit stocker différents types de données et nécessite une interface graphique différente pour le créateur et pour le candidat.

Je voudrais éviter deux choses:

1. Contrôles de type ou transtypage
2. Tout ce qui concerne l'interface graphique dans mon code de données.

Dans ma première tentative, je me retrouve avec les classes suivantes:

class Test{
    List<Question> questions;
}
interface Question { }
class MultipleChoice implements Question {}
class TextBox implements Question {}

Cependant, lorsque je vais afficher le test, je me retrouverais inévitablement avec du code comme:

for (Question question: questions){
    if (question instanceof MultipleChoice){
        display.add(new MultipleChoiceViewer());
    } 
    //etc
}

Cela ressemble à un problème très courant. Y a-t-il un modèle de conception qui me permet d'avoir des questions polymorphes tout en évitant les éléments énumérés ci-dessus? Ou le polymorphisme est-il une mauvaise idée en premier lieu?

Vous pouvez utiliser un modèle de visiteur:

interface QuestionVisitor {
    void multipleChoice(MultipleChoice);
    void textBox(TextBox);
    ...
}

interface Question {
    void visit(QuestionVisitor);
}

class MultipleChoice implements Question {

    void visit(QuestionVisitor visitor) {
        visitor.multipleChoice(this);
    }
}

Une autre option est une union discriminée. Cela dépendra beaucoup de votre langue. C'est beaucoup mieux si votre langue le prend en charge, mais pas beaucoup de langues populaires.

En C # / WPF (et, j'imagine, dans d'autres langages de conception axés sur l'interface utilisateur), nous avons des DataTemplates . En définissant des modèles de données, vous créez une association entre un type «d'objet de données» et un «modèle d'interface utilisateur» spécialisé créé spécifiquement pour afficher cet objet.

Une fois que vous avez fourni des instructions pour que l'interface utilisateur charge un type spécifique d'objet, il verra s'il existe des modèles de données définis pour l'objet.

Si chaque réponse peut être codée sous forme de chaîne, vous pouvez le faire:

interface Question {
    int score(String answer);
    void display(String answer);
    void displayGraded(String answer);
}

Où la chaîne vide signifie une question sans réponse pour le moment. Cela permet de séparer les questions, les réponses et l'interface graphique tout en permettant le polymorphisme.

class MultipleChoice implements Question {
    MultipleChoiceView mcv;
    String question;
    String answerKey;
    String[] choices;

    MultipleChoice(
            MultipleChoiceView mcv, 
            String question, 
            String answerKey, 
            String... choices
    ) {
        this.mcv = mcv;
        this.question = question;
        this.answerKey = answerKey;
        this.choices = choices;
    }

    int score(String answer) {
        return answer.equals(answerKey); //Or whatever scoring logic
    }

    void display(String answer) {
        mcv.display(question, choices, answer);            
    }

    void displayGraded(String answer) {
        mcv.displayGraded(
            question, 
            answerKey, 
            choices, 
            answer, 
            score(answer)
        );            
    }
}

La zone de texte, la correspondance, etc. pourraient avoir des conceptions similaires, implémentant toutes l'interface de question. La construction de la chaîne de réponse se produit dans la vue. Les chaînes de réponse représentent l'état du test. Ils doivent être conservés au fur et à mesure que l'élève progresse. Les appliquer aux questions permet d'afficher le test et son état à la fois gradué et non gradué.

En séparant la sortie display()et displayGraded()la vue n'a pas besoin d'être échangée et aucune ramification ne doit être effectuée sur les paramètres. Cependant, chaque vue est libre de réutiliser autant de logique d'affichage que possible lors de l'affichage. Quel que soit le schéma conçu pour le faire, il n'a pas besoin de fuir dans ce code.

Si, cependant, vous souhaitez avoir un contrôle plus dynamique de l'affichage d'une question, vous pouvez le faire:

interface Question {
    int score(String answer);
    void display(MultipleChoiceView mcv, String answer);
}

et ça

class MultipleChoice implements Question {
    String question;
    String answerKey;
    String[] choices;

    MultipleChoice(
            String question, 
            String answerKey, 
            String... choices
    ) {
        this.question = question;
        this.answerKey = answerKey;
        this.choices = choices;
    }

    int score(String answer) {
        return answer.equals(answerKey); //Or whatever scoring logic
    }

    void display(MultipleChoiceView mcv, String answer) {
        mcv.display(
            question, 
            answerKey, 
            choices, 
            answer, 
            score(answer)
        );            
    }
}

Cela présente l'inconvénient de nécessiter des vues qui n'ont pas l'intention d'afficher score()ou answerKeyde dépendre d'eux lorsqu'elles n'en ont pas besoin. Mais cela signifie que vous n'avez pas à reconstruire les questions de test pour chaque type de vue que vous souhaitez utiliser.

À mon avis, si vous avez besoin d'une telle fonctionnalité générique, je diminuerais le couplage entre les éléments du code. J'essaierais de définir le type de question le plus générique possible, puis je créerais différentes classes pour les objets de rendu. Veuillez consulter les exemples ci-dessous:

///Questions package

class Test {
  IList<Question> questions;
}

class Question {
  String Type;   //example; could be another type
  IList<QuestionInfo> Info;  //Simple array of key/value information
}

Ensuite, pour la partie de rendu, j'ai supprimé la vérification de type en implémentant une simple vérification des données dans l'objet question. Le code ci-dessous essaie d'accomplir deux choses: (i) éviter la vérification de type et éviter la violation du principe "L" (substitution Liskov dans SOLID) en supprimant le sous-typage de la classe Question; et (ii) rendre le code extensible, en ne modifiant jamais le code de rendu principal ci-dessous, en ajoutant simplement plus d'implémentations QuestionView et ses instances au tableau (c'est en fait le principe "O" dans SOLID - ouvert pour extension et fermé pour modification).

///GUI package

interface QuestionView {
  Boolean SupportsQuestion(Question question);
  View CreateView(Question question);
}

class MultipleChoiceQuestionView : QuestionView {
  Boolean SupportsQuestion(Question question){
    return question.Type == "multiple_coice";
  }

  //...more implementation
}
class TextBoxQuestionView : QuestionView { ... }
//...more views

//Assuming you have an array of QuestionView pre-configured
//with all currently available types of questions
for (Question question : questions) {
  for (QuestionView view : questionViews) {
    if (view.SupportsQuestion(question)) {
        display.add(view.CreateView(question));
    }
  }
}

Une usine devrait pouvoir le faire. La carte remplace l'instruction switch, qui est uniquement nécessaire pour associer la question (qui ne sait rien de la vue) avec la questionView.

interface QuestionView<T : Question>
{
    view();
}

class MultipleChoiceView implements QuestionView<MultipleChoiceQuestion>
{
    MultipleChoiceQuestion question;
    view();
}
...

class QuestionViewFactory
{
    Map<K : Question, V : QuestionView<K>> map;

    register<K : Question, V : QuestionView<K>>();
    getView(Question)
}

Avec cela, la vue utilise le type spécifique de question qu'elle est capable d'afficher, et le modèle reste déconnecté de la vue.

L'usine peut être remplie par réflexion ou manuellement au démarrage de l'application.

Je ne suis pas sûr que cela compte comme "éviter les vérifications de type", selon ce que vous pensez de la réflexion .

// Either statically associate or have a register(Class, Supplier) method
Dictionary<Class<? extends Question>, Supplier<? extends QuestionViewer>> 
viewerFactory = // MultipleChoice => MultipleChoiceViewer::new etc ...

// ... elsewhere

for (Question question: questions){
    display.add(viewerFactory[question.getClass()]());
}