Results 1 to 2 of 2
  1. #1
    raindog308 is offline Member
    Join Date
    Jan 2011
    Posts
    3
    Rep Power
    0

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

    Thanks!

  2. #2
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,797
    Rep Power
    19

    Default

    When requesting the info for a particular Column does the requesting thing know what Dataset the Column is a part of?
    If so then place the request call into the Dataset. This will pass the call down to the Table which will pass it to the Column. If the Column returns null (ie "I don't have this") then the Table looks. If the Table doesn't have that thing then it returns null and the Dataset will return its own value.

    Something like:
    Java Code:
    // Dataset
    public Option getOption(OptionType type, Table table, Column column) {
    // if getOption on the table is not null then return that else return
    // return the result of get(key) from my Map<OptionType, Option> for the Option.
    }
    
    // Table
    public Option getOption(OptionType type, Column column) {
    // if getOption on the column is not null then return that else return
    // return the result of get(key) from my Map<OptionType, Option> for the Option.
    }
    
    // Column
    public Option getOption(OptionType type) {
    // return the result of get(key) from my Map<OptionType, Option> for the Option.
    }
    Now, this is based on a not terribly detailed knowledge of your system, but it's the sort of way I'd go. This way a Column does not have to know what Table (or dataset) it belongs to) etc.

    If you aren't working down from Datasets then Tables and Columns will have to know something about their parents.

Similar Threads

  1. Command design pattern
    By hannes in forum AWT / Swing
    Replies: 10
    Last Post: 01-28-2010, 06:41 AM
  2. question on j2ee design pattern
    By Minu in forum Advanced Java
    Replies: 1
    Last Post: 01-06-2009, 07:50 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •