Come si crea una GUI per una classe polimorfica?

Diciamo che ho un costruttore di test, in modo che gli insegnanti possano creare una serie di domande per un test.

Tuttavia, non tutte le domande sono uguali: puoi scegliere tra più opzioni, casella di testo, corrispondenza e così via. Ognuno di questi tipi di domande deve memorizzare diversi tipi di dati e necessita di una GUI diversa sia per il creatore che per chi esegue il test.

Vorrei evitare due cose:

1. Tipo controlli o tipo casting
2. Tutto ciò che riguarda la GUI nel mio codice dati.

Nel mio tentativo iniziale, finisco con le seguenti classi:

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

Tuttavia, quando vado a visualizzare il test, finirei inevitabilmente con un codice come:

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

Sembra un problema davvero comune. Esiste un modello di progettazione che mi consente di avere domande polimorfiche evitando gli elementi sopra elencati? O il polimorfismo è l'idea sbagliata in primo luogo?

È possibile utilizzare un modello visitatore:

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

interface Question {
    void visit(QuestionVisitor);
}

class MultipleChoice implements Question {

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

Un'altra opzione è un'unione discriminata. Questo dipenderà molto dalla tua lingua. Questo è molto meglio se la tua lingua lo supporta, ma molte lingue popolari no.

In C # / WPF (e, immagino, in altri linguaggi di progettazione incentrati sull'interfaccia utente), abbiamo DataTemplates . Definendo i modelli di dati, si crea un'associazione tra un tipo di "oggetto dati" e un "modello UI" specializzato creato appositamente per visualizzare quell'oggetto.

Una volta fornite le istruzioni per l'interfaccia utente per caricare un tipo specifico di oggetto, vedrà se ci sono modelli di dati definiti per l'oggetto.

Se ogni risposta può essere codificata come stringa, puoi farlo:

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

Dove la stringa vuota indica una domanda senza risposta. Ciò consente di separare le domande, le risposte e la GUI ma consente il polimorfismo.

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

Casella di testo, corrispondenza e così via potrebbero avere progetti simili, tutti implementando l'interfaccia della domanda. La costruzione della stringa di risposta avviene nella vista. La stringa di risposta rappresenta lo stato del test. Dovrebbero essere archiviati man mano che lo studente avanza. Applicandoli alle domande è possibile visualizzare il test ed è lo stato in modo sia graduale sia non classificato.

Separando l'output in display()e displayGraded()la vista non deve essere scambiata e non è necessario eseguire la ramificazione sui parametri. Tuttavia, ogni visualizzazione è libera di riutilizzare quanta più logica di visualizzazione possibile durante la visualizzazione. Qualunque schema sia stato concepito per fare ciò, non è necessario infiltrarsi in questo codice.

Se, tuttavia, desideri avere un controllo più dinamico su come viene visualizzata una domanda, puoi farlo:

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

e questo

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

Ciò ha lo svantaggio di richiedere viste che non intendono visualizzare score()o answerKeydipendere da esse quando non ne hanno bisogno. Ciò significa che non è necessario ricostruire le domande del test per ogni tipo di vista che si desidera utilizzare.

Secondo me, se hai bisogno di una funzionalità così generica, diminuirei l'accoppiamento tra elementi nel codice. Vorrei provare a definire il tipo di domanda il più generico possibile e, successivamente, creerei diverse classi per gli oggetti renderer. Si prega di vedere gli esempi seguenti:

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

Quindi, per la parte di rendering, ho rimosso il controllo del tipo implementando un semplice controllo sui dati all'interno dell'oggetto della domanda. Il codice seguente cerca di realizzare due cose: (i) evitare la verifica del tipo ed evitare la violazione del principio "L" (sostituzione di Liskov in SOLID) rimuovendo il sottotipo della classe Domanda; e (ii) rendere estensibile il codice, non modificando mai il codice di rendering di base riportato di seguito, semplicemente aggiungendo più implementazioni di QuestionView e le sue istanze all'array (questo è in realtà il principio "O" in SOLID - aperto per l'estensione e chiuso per modifica).

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

Una fabbrica dovrebbe essere in grado di farlo. La mappa sostituisce l'istruzione switch, necessaria solo per accoppiare la domanda (che non sa nulla della vista) con 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)
}

In questo modo la vista utilizza il tipo specifico di domanda che è in grado di visualizzare e il modello rimane disconnesso dalla vista.

La fabbrica può essere popolata tramite riflessione o manualmente all'avvio dell'applicazione.

Non sono sicuro che questo valga come "evitare i controlli del tipo", a seconda di come ti senti riguardo alla riflessione .

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