ポリモーフィッククラスのGUIはどのように作成しますか？

テストビルダーがあり、教師がテスト用の一連の質問を作成できるようにしたとします。

ただし、すべての質問が同じというわけではありません。複数の選択肢、テキストボックス、一致などがあります。これらの質問タイプはそれぞれ、異なるタイプのデータを保存する必要があり、作成者と受験者の両方に異なるGUIが必要です。

私は2つのことを避けたいです：

1. 型チェックまたは型キャスト
2. データコード内のGUIに関連するもの。

私の最初の試みでは、次のクラスになりました。

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

ただし、テストを表示すると、必然的に次のようなコードになります。

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

これは本当に一般的な問題のように感じます。上記の項目を避けながら、多態的な質問をすることができるデザインパターンはありますか？それとも、多型はそもそも間違った考えですか？

ビジターパターンを使用できます。

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

interface Question {
    void visit(QuestionVisitor);
}

class MultipleChoice implements Question {

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

別のオプションは、差別化された組合です。これはあなたの言語に大きく依存します。お使いの言語がサポートしている場合、これははるかに優れていますが、多くの一般的な言語はサポートしていません。

C＃/ WPF（および、私が想像するように、他のUI中心の設計言語）には、DataTemplatesがあります。データテンプレートを定義することにより、1つのタイプの「データオブジェクト」と、そのオブジェクトを表示するために特別に作成された特殊な「UIテンプレート」との間に関連付けを作成します。

特定の種類のオブジェクトを読み込むためのUIの指示を提供すると、オブジェクトにデータテンプレートが定義されているかどうかがわかります。

すべての回答を文字列としてエンコードできる場合、これを行うことができます：

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

空の文字列は、まだ答えのない質問を意味します。これにより、質問、回答、およびGUIを分離できますが、ポリモーフィズムも可能です。

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)
        );            
    }
}

テキストボックス、マッチングなどに同様のデザインを使用し、すべて質問インターフェイスを実装できます。回答文字列の構築は、ビューで行われます。回答文字列はテストの状態を表します。生徒の進行に合わせて保存する必要があります。それらを質問に適用すると、テストとその状態を段階的な方法と非段階的な方法の両方で表示できます。

出力を分離することによってdisplay()、およびdisplayGraded()ビューをスワップアウトする必要はありませんし、何の分岐ニーズがパラメータに行われないことを。ただし、各ビューは、表示時に可能な限り多くの表示ロジックを自由に再利用できます。どのようなスキームが考案されていても、このコードにリークする必要はありません。

ただし、質問の表示方法をより動的に制御したい場合は、これを行うことができます。

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

この

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)
        );            
    }
}

これには、表示する必要がないビューscore()や、必要のないビューanswerKeyに依存するビューが必要になるという欠点があります。ただし、使用するビューのタイプごとにテスト問題を再作成する必要はありません。

私の意見では、このような一般的な機能が必要な場合は、コード内の要素間の結合を減らします。できるだけ一般的な質問タイプを定義しようとし、その後、レンダラーオブジェクト用に異なるクラスを作成します。以下の例をご覧ください。

///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
}

次に、レンダリング部分について、質問オブジェクト内のデータに簡単なチェックを実装することにより、タイプチェックを削除しました。以下のコードは、2つのことを達成しようとします。（i）Questionクラスのサブタイプを削除することにより、型チェックを回避し、「L」原則（SOLIDのLiskov置換）の違反を回避します。（ii）以下のコアレンダリングコードを変更せずに、コードを拡張可能にします。QuestionViewの実装とそのインスタンスを配列に追加するだけです（これは実際にはSOLIDの「O」の原則です。

///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));
    }
  }
}

工場はこれを行うことができるはずです。マップはswitchステートメントを置き換えます。switchステートメントは、Question（ビューについて何も知らない）と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)
}

これにより、ビューは表示可能な特定のタイプの質問を使用し、モデルはビューから切断されたままになります。

ファクトリは、リフレクションを介して、またはアプリケーションの起動時に手動で設定できます。

あなたがリフレクションについてどのように感じるかに応じて、これが「型チェックの回避」としてカウントされるかどうかわかりません。

// 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()]());
}