Как вы делаете GUI для полиморфного класса?

Допустим, у меня есть конструктор тестов, чтобы учителя могли создать кучу вопросов для теста.

Однако не все вопросы одинаковы: у вас есть несколько вариантов выбора, текстовое поле, соответствие и т. Д. Каждый из этих типов вопросов должен хранить разные типы данных и иметь разные графические интерфейсы как для создателя, так и для тестируемого.

Я хотел бы избежать двух вещей:

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 (и, я полагаю, в других языках проектирования, ориентированных на пользовательский интерфейс) у нас есть DataTemplates . Определяя шаблоны данных, вы создаете связь между одним типом «объекта данных» и специализированным «шаблоном пользовательского интерфейса», созданным специально для отображения этого объекта.

Как только вы предоставите инструкции для пользовательского интерфейса для загрузки объекта определенного типа, он увидит, есть ли какие-либо шаблоны данных, определенные для объекта.

Если каждый ответ может быть закодирован как строка, вы можете сделать это:

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

Где пустая строка означает вопрос без ответа. Это позволяет разделять вопросы, ответы и графический интерфейс, но при этом допускает полиморфизм.

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
}

Затем для части рендеринга я удалил проверку типа, реализовав простую проверку данных в объекте вопроса. Приведенный ниже код пытается выполнить две вещи: (i) избежать проверки типов и избежать нарушения принципа «L» (подстановка Лискова в SOLID), удалив подтип класса Question; и (ii) сделать код расширяемым, никогда не меняя основной код рендеринга ниже, просто добавляя больше реализаций QuestionView и его экземпляров в массив (это на самом деле принцип «O» в SOLID - открытый для расширения и закрытый для модификации).

///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, который необходим исключительно для сопряжения Вопроса (который ничего не знает о представлении) с 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()]());
}