In my application, I have a finite number of question types, but the order in which they're asked and whether they're asked at all is not known up-front.

An example analogy is a hotel booking process, during the process you may be asked a number of questions, like whether you want late check-out, rent-a-car, breakfast-selection.

interface IAncillary
    string FormType { get; }
    object GetViewData();
    void SaveResponse(object response);
    void Skip();

class LateCheckOutAncillary : IAncillary
    public FormType { get; } = "late-check-out";

    public object GetViewData()
        return new LateCheckOutOption[] 
            new LateCheckOutOption("2pm", 50m),
            new LateCheckOutOption("4pm", 75m)

    public void SaveResponse(object response)
        // record in database (string response).
        // potentially add another ancillary

    public void Skip()
        // record in database.
        // potentially add a different ancillary or 
        // remote other ancillaries

My initial thought is that the State Design Pattern is most applicable, however, the problem for me is that the view data format and response format is different per ancillary. It'll most likely be represented as a Wizard to the end-user, but I haven't found any design pattern that solves this.

All ancillaries have a Skip option which is to be used if the client does not understand the FormType.

The ancillaries use object for view data and object for response data, so if there's something that can account for that too it would be nice.

Ultimately this will need to be represented as an HTTP interface, however, I'm still wrapping my head around how I would express it with an object oriented language first.

What design pattern would be best used for representing a set of sequential questions where each question is in a different format?

closed as too broad by Robert Harvey Jun 4 at 1:58

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    "Series of questions" describes every UI, ever. Usually what you do is define a DTO with one field per answer, each strongly typed, and then develop UI assets to prompt and populate per field. Engineering some sort of general representation of a "question" that can be put into a list-- that is often counterproductive. The range of values, validation rules, and dependencies etc. are peculiar to each field, usually, and are almost always going to require unique UI code. An exception would be something like a questionnaire or an exam, or if the questions themselves can be configured at run time. – John Wu Jan 4 at 17:33
  • Do you supply the HTTP interface too, or is this some form of framework which will be used in all sorts of different GUIs? – Robert Bräutigam Jan 9 at 19:55
  • It will be on an HTTP interface transmitting a JSON response body, but we won't be dictating the layout or HTML, that will be up to consumers of the API. – Matthew Jan 9 at 21:51

Read @JohnWu comment. My answer will echo much of that I expect.

My initial thought is that the State Design Pattern is most applicable

The state machine idea could apply in "the big picture". For example a player is scored only when in the "questions completed" state.

If anything, MVC applies here because the fundamental issue is displaying data with some UI variations. The Controller maps the data to the screen elements. I know you're thinking about minute details that must be addressed with a fundamental data structure.

Beware a solution looking for a problem

Be sure you do not pick patterns and then force your code design to conform. Design your app - get started at least - then see if any patterns apply as you go along. Studying patterns generally can give you some ideas without applying designs explicitly.

Design the data structure, worry about UI separately

Good data structure will make it usable with "view" design patterns like MVC. You want to make a "questions API" that is robust enough to construct the structure, maintain internal integrity, pull data for database storage as well as mapping onto any GUI - be able to handle those IAncillary variations. Whatever it looks like it is never merely strings independently floating free.

Let's make a quick sketch:

// not deciding on abstract classes, interfaces, yet.
public class Question {
   protected Answers answers = null;
   protected string question = string.Empty;
   protected bool correct = false;
   protected ???? questionType;  // I like enums

   public Answer CorrectAnswer () { return answers.CorrectAnswer(); }

   public bool isCorrect { return correct; } 
   // how do we know the question was asked and answered yet? 
   // I suppose if unanswered it must be wrong. This class does not
   // know if it was asked, that's the GUI's business.

   public void GradeResponse (Answer theResponse) { ... }
   // should/could this called inside of "CorrectAnswer()" and/or "isCorrect"? 
   //Would it have to be "public"?

public class Answer { 
   protected bool theRightAnswer = false;

   public bool CorrectAnswer { return theRightAnswer; }

public class Answers { 
   protected List<Answer> answers = null;

   public bool CorrectAnswer { return answers.find( x => x.CorrectAnswer == true) }
   // is there only 1 right answer? If so, how is that guaranteed?

public class Questions { 
   protected List<Question> questions = null;

   public Questions GetType(QuestionType thisKind) {
      Questions oneKindOf = new Questions();

      oneKindOf =  this.questions.FindAll(x => x.questionType == thisKind);
      return oneKindOf;

Whatever your final solution there should be classes like these. Even if they are very simple.

Data structure design patterns

Research "construction" design patterns, particularly Factory and Builder

Not the answer you're looking for? Browse other questions tagged or ask your own question.