Domain Modeling of Surveys

One of the great things about domain models is no matter how many times you return to them, you will see new things. Well, let me qualify that. Like the scene in Moby Dick where Ahab nails the Doubloon to the mast, you should see something different on looking again, but you might not. People with Dunning-Kruger(I found this thing a year ago using StumbleUpon but then a friend relit this for me recently, having seen that Errol Morris has gone completely kuckoo on it) are less likely to because the mere idea that they might let doubt into a prior rendering on a subject would never enter their minds. I like the Russell quote more than the Yeats one, also because it ties to my favorite Voltaire quote: ‘Doubt is painful, certainty ridiculous.‘ (More on the ridiculousness of people who think they know everything later…)

Anyway, in revisiting Surveys I immediately saw something different. In the past I noticed that Surveys and Tests are good examples of Prototypes because the same name is used for the Test the teacher makes as the one the student gets. The copying done in between corresponds to the cloning the Prototype Pattern stipulates. This time around, the benefits of Prototype seem less compelling because the test itself is something that will have to be made.

The biggest problem with Surveys is actually types. The reason is simple: there are different types of Questions, and those use different types. If we were just doing multiple choice, then the model would be pretty simple. [See the included figure.] There are multiple choices for each question and the response is a respondent picking one. This would be a fine, clean model.

The problem is that surveys consist of two spoilers: 1. questions that are just open ended, meaning the response is just free text, and 2. there are multiple answer questions, e.g., if I was screening candidates for a job (not the kind of job people here talk about hiring for), I might say which of the 4 choices below are patterns from the Gang of Four book?

Here‘s where the Java programmer will probably fall on his face. I think most are going to go in one of two directions: either, question is a common base class but the only thing all the types have in common is that they have a string which is the prompt to the respondent. On the response side, again, you could make a base class, but the return types would all be different. For the open ended one, we get a String, multiple choice, a single Choice, multiple answer a collection of Choices.

The compromise position is to make a model where the response has a collection of Choices. The collection is empty for the open ended one, has only one entry for the multiple choice, and has multiple for the multiple answer question type. The problem with this is that the data model is not really proper because the constraints cannot be declared as part of the model: they‘ve spilled into the code.

As fate would have it, I‘ve been using Objective-C lately, and think that this could be a really good case for a dynamically typed language. I totally disagree with the idea that dynamic typing means bad names and mislabeled assignments. Let‘s face the facts, Folks: generics, as great as they are, solve problems in a way that is unnatural: by making you have to have collections only of things that are the same types. Models like this, where the whole idea of a Survey is that it contains questions, but the questions are so different that they are essentially all different types. Having different collections for the various supported types would be a ludicrous solution.

Look at this another way: ultimately, we have to store the responses. If all I do with the dynamic typing is use forwarding so that the constraints are explicitly accounted for, that would be better, and I could still have a simple clean model. Will post again when I am done with it. One last thing: on the Survey side, I decided that instead of seeing it as a prototype (same name for template and individual instance), it made more sense to model it as the Survey is actually a collection of Questionnaires. Make sense etymologically as well, because you participate in a Survey, but to Survey implies aggregates: a single response is not a Survey. (Names are important.)

From http://www.jroller.com/robwilliams/entry/domain_modeling_of_surveys