Modeling -- how to support multiple views of same components?

Discussion in 'Ruby' started by Trans, Jul 25, 2007.

  1. Trans

    Trans Guest

    I have a little design conundrum. I'm not sure the best way to model
    this. Basically I have two model "parts" and I want to support two
    ways of using them. Eg.

    class Part1
    attr_accessor :a, :b, :x
    end

    class Part2
    attr_accessor :x, :y, :z
    end

    Now in the first case I want effectively:

    class Model1 < Part1
    def subpart
    @subpart ||= Part2.new
    end
    end

    but in the second I want the equivalent of:

    class Model2 < Part1 < Part2

    but obviously I can't do multiple inheritance.

    So I've been trying to figure out the best way to do it. Do I use
    modules? Do I use Forwardable? What's the cleanest, fastest, least
    troubling way to go about it?

    Thanks,
    T.
     
    Trans, Jul 25, 2007
    #1
    1. Advertising

  2. On 25.07.2007 23:11, Trans wrote:
    > I have a little design conundrum. I'm not sure the best way to model
    > this. Basically I have two model "parts" and I want to support two
    > ways of using them. Eg.
    >
    > class Part1
    > attr_accessor :a, :b, :x
    > end
    >
    > class Part2
    > attr_accessor :x, :y, :z
    > end
    >
    > Now in the first case I want effectively:
    >
    > class Model1 < Part1
    > def subpart
    > @subpart ||= Part2.new
    > end
    > end
    >
    > but in the second I want the equivalent of:
    >
    > class Model2 < Part1 < Part2
    >
    > but obviously I can't do multiple inheritance.
    >
    > So I've been trying to figure out the best way to do it. Do I use
    > modules? Do I use Forwardable? What's the cleanest, fastest, least
    > troubling way to go about it?


    It's difficult to comment without knowing the domain or your use case.
    IMHO the fact that you want different inheritance hierarchies indicates
    that there is something wrong, namely inheritance might not be the best
    approach here. It seems like composition would be better but since I do
    not know what you are doing please take this with a large grain of salt.

    Can you disclose more detail?

    Kind regards

    robert
     
    Robert Klemme, Jul 26, 2007
    #2
    1. Advertising

  3. Trans

    Trans Guest

    On Jul 26, 10:55 am, Robert Klemme <> wrote:

    > Can you disclose more detail?


    Sure. It's for configuration information. On the one hand, I want to
    be able to read package settings from a file that is strictly
    dedicated to packaging. So, for instance my project might have
    a .package file that has basically:

    project: foo
    version: 1.1
    dependencies: [ facets ]
    formats: [zip, tgz, gem]

    However, I also want to support an uber-project configuration file,
    that would look like:

    project: foo
    version: 1.1
    package:
    dependencies: [ facets ]
    formats: [zip, tgz, gem]

    So I have two slightly different formats that I want to support with
    strict classes. Eg. in the first case:

    pkg = Package.load(file)
    pkg.project #=> 'foo'
    pkg.formats #=> ['zip','tgz','gem']

    and in the other:

    pkg = Project.load(file)
    pkg.project #=> 'foo'
    pkg.package.formats #=> ['zip','tgz','gem']

    So, the same info, but organized in the two different manners, as I
    described in the original post.

    Note, by "strict class" I mean I'm not just keying off a YAML-loaded
    hash. I need a class b/c various attributes have default values,
    validation and formating applied, plus supporting methods.

    T.
     
    Trans, Jul 26, 2007
    #3
  4. Trans

    Robert Dober Guest

    On 7/25/07, Trans <> wrote:
    You just recently accepted a patch for snapshot, right?
    A nice one indeed I think.
    Does this ring the same bells to you than to me?

    I am thinking of manipulating Hashes instead of classes, did I miss
    something or might it work?

    Well from the design point of view that would recall Module Inclusion.

    Cheers
    Robert

    >
    >
    >



    --
    [...] as simple as possible, but no simpler.
    -- Attributed to Albert Einstein
     
    Robert Dober, Jul 26, 2007
    #4
  5. On 26.07.2007 21:18, Trans wrote:
    >
    > On Jul 26, 10:55 am, Robert Klemme <> wrote:
    >
    >> Can you disclose more detail?

    >
    > Sure. It's for configuration information. On the one hand, I want to
    > be able to read package settings from a file that is strictly
    > dedicated to packaging. So, for instance my project might have
    > a .package file that has basically:
    >
    > project: foo
    > version: 1.1
    > dependencies: [ facets ]
    > formats: [zip, tgz, gem]
    >
    > However, I also want to support an uber-project configuration file,
    > that would look like:
    >
    > project: foo
    > version: 1.1
    > package:
    > dependencies: [ facets ]
    > formats: [zip, tgz, gem]
    >
    > So I have two slightly different formats that I want to support with
    > strict classes. Eg. in the first case:
    >
    > pkg = Package.load(file)
    > pkg.project #=> 'foo'
    > pkg.formats #=> ['zip','tgz','gem']
    >
    > and in the other:
    >
    > pkg = Project.load(file)
    > pkg.project #=> 'foo'
    > pkg.package.formats #=> ['zip','tgz','gem']
    >
    > So, the same info, but organized in the two different manners, as I
    > described in the original post.
    >
    > Note, by "strict class" I mean I'm not just keying off a YAML-loaded
    > hash. I need a class b/c various attributes have default values,
    > validation and formating applied, plus supporting methods.


    So as far as I can see you have these requirements:

    1. reuse of config parameters and their defaults in multiple places

    2. default values for config parameters

    3. supporting functionality (whatever that is)

    Some random thoughts (as I'm pretty tired already): Personally I'd limit
    3 to a bare minimum. I am sure there are multiple ways to handle
    default values (for example, using a template of nested Hashes and
    merging that with something parsed from the config file). OpenStruct or
    a similar concept might come in handy. Is validation of config values
    better done in (generic?) config classes or in application classes (I
    tend to believe the latter, because ensuring proper arguments is a task
    of the model). Hm... Probably not too useful. Maybe I have more ideas
    after sleeping. :)

    Kind regards

    robert
     
    Robert Klemme, Jul 26, 2007
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mickey Segal
    Replies:
    0
    Views:
    905
    Mickey Segal
    Feb 2, 2004
  2. tenxian
    Replies:
    2
    Views:
    428
    Arne Vajhøj
    Apr 8, 2008
  3. Clifford Heath
    Replies:
    2
    Views:
    197
    Clifford Heath
    Feb 7, 2007
  4. adambones
    Replies:
    3
    Views:
    118
    Thomas 'PointedEars' Lahn
    Aug 7, 2008
  5. Rob Clewley
    Replies:
    0
    Views:
    143
    Rob Clewley
    Feb 20, 2013
Loading...

Share This Page