A little design (pattern?) question...
I have a set of user-choice options for a database program. Some options apply at the (entire) Dataset level, some at the Table level, and some at the Column level. Some are required, some are not. Some are available at all levels (e.g., "date format to use") with column overriding table, which overrides global. If Column doesn't specify what date format to use, then the Table's date format is used, and if Table doesn't specify, then the Dataset (which always has a default) is used. Some options are booleans, some integers, etc.
To keep track of these options, I'm wondering if this suggests a particular design pattern or structure I should use.
My first thought was to have a Dataset object, which contains Table objects, which contain Column objects. Each would then have the various options as simple fields within the object. The problem is if someone says "hey Column, what's your date format?" I'm not sure how it'd say "I don't have a specific one - use what the Table I belong to wants to use".
There really isn't a class or inheritance relationship between Dataset/Table/Column - one just happens to hold a bunch of the other.
Perhaps I should have some sort of Option object, but I'm not sure if there is a particular pattern or structure that suggests itself.
If anyone has any ideas, I would love to hear them, otherwise I'll just keep sketching on my whiteboard ;-)