Defining the structure of hierarchical data versus actually storing the data

I'm trying to develop a survey application that can deal with various types of responses, such as boolean, multiple choice, as well as ranges from 1-5, 1-10, 1-100, -2 to +2, even decimal values. So, I've created a hie开发者_如何学JAVArarchy of Response types:

class Response {
        String name
}

class BooleanResponse extends Response {
        boolean score
}

class SimpleGradeResponse extends Response {
        char score // A-F
}

class ComplexGradeResponse extends Response {
        char score // A-F
        char modifier // +, -, blank
}

class IntegerResponse extends Response {
        int min, max, score
}

class DecimalResponse extends Response {
        double min, max, score
}

I think of that as the metadata. It describes the survey response types. You could have question 1 that's an IntegerResponse from 1 to 10, question 2 that's an IntegerResponse from 0-100, question 3 that's a DecimalResponse, etc.

Where I'm uncertain is where to store the actual responses from users. Do you mingle the scores in with the metadata, as I've done with the score field above? That seems awkward, since every range-type response carries with it the min and max.

What I really want (I think) is to be able to curry the range response parameters to create a new type, and then reflect that type in a table of actual responses. So, a question that takes a 1-10 range would be a row in IntegerResponse with min=1 and max=10. But how does the ActualResponse table (I need to improve the naming convention, once I figure this out!) hold a score and refer to the curried IntegerResponse with min and max set?

If there is a better way to approach this whole problem, I'm eager to hear it.

Thanks, Lee

1. min and max should rather be stored in a Question object, or even in QuestionType - depending on how flexible the system should be in runtime.
2. Will there be arbitrary limitations to different kinds of Responses? Data structure hugely depends on it. You can either hardcode different Response types or support them in runtime. First approach is one order of magnitude simpler.