in reply to Re: Design Question - I've gone object mad!
in thread Design Question - I've gone object mad!

I have come across this thought from my fellow monks in the past, yet I still can't seem to see how, possibly not seeing the woods through the trees.

In my example, a My::Customer may work in a My::Industry. They'll need to select a My::Industry on a form.

This all leads me to needing to get a list of possible industries, and tying the two together through their IDs.

Somewhere else I may need to get all My::Customer objects that registered last month, last year, 2 weeks ago, etc, hence the need for some sort of...

My::Customer->get( registered => [ DateTime->new( year => 2011, month +=> 4, day => 1 ), '>' ] );

...approach.

I'd love to sit down and talk this idea of modelling processes more than the objects themselves with a fellow monk, but unfortunately I currently work pretty much alone, while training up 2 others.

I presume my original approach to be "ok", I think I've asked a similar question before and it usually goes on this same tangent of the modelling rather than the interface.

Replies are listed 'Best First'.
Re^3: Design Question - I've gone object mad!
by choroba (Cardinal) on Apr 06, 2011 at 09:37 UTC
    Somehow, I do not like the '<' string. Cannot you supply a sub ref that will return the values you need, i.e. similarly to sort:
    My::Customer->get( registered => [ DateTime->new( year => 2011, month +=> 4, day => 1 ), \&greater ] );
    You can than define between etc.

      Me neither, that string isn't very nice.

      An interesting approach you suggest, this is what I was after! :)

      Tho that does make the code look a bit messier - maybe some more encapsulation around it...

      My::Customer->get( registered => [ $datetime, My::Operator->greater ] +); package My::Operator; sub greater { return '>'; # or something more fully fledged! }
Re^3: Design Question - I've gone object mad!
by Voronich (Hermit) on Apr 06, 2011 at 14:26 UTC
    Indeed. I'll chime in with the reassurance that there's little "wrong" with the modelling of 'physical' objects.

    It tends to be a bit heavy weighted later on. But refactor it a bit at a time. For instance, everything you describe sounds ok. But I don't have to work with it, so it's tough to figure out where the sticking points are. All I can really advise is to pay very close attention to "I wish I could just...." thoughts. Optimistically write it top-down as far as you can, then the design difficulties will emerge in a pretty clear way.

    Either way, sounds like your thinking on the right lines.

    Me