database-centric point of view. So, I'm having a hard time changing that
line of thinking.
Okay, so if I go with a two object model (grossly simplified, of course),
then I have a "consumables" object as an attribute of my task object? Is
that correct? So, if I instantiate a consumables object inside my task
object, I can then call the method "getallConsumables" and get all the
consumables for that task.
Do I do all my new consumable creation from within my task object, too? Or,
do I instantiate outside the task object and just pass in a taskid when I
want to add a consumable (to the database)?
So, my SnapShot would be something like this:
Sue has a "Videotape Interviews" task in the system. The task involves $500
worth of videographer's service (considered a consumable good). Sue needs to
enter the amount and type of consumables used into the system.
Procedurally, it would go like this (skipping a bunch of steps to get to
this point):
1. Sue selects the "Videotape Interviews" task from her drop down list of
tasks. (A query result set of all Sue's tasks.)
2. Sue selects "manage consumables" from her "to do" list. (A standard list
of things we can do with tasks.)
3. Sue enters the type and amount of consumables, and optionally a date
(defaults to today). (An html form page)
4. A new consumable is added to the database for the selected task. (An
action page with a cfquery.)
Sample object-centric interpretation anyone?
----- Original Message -----
From: "Ben Doom" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Tuesday, November 18, 2003 1:36 PM
Subject: Re: SOT: OO Design
> Holy crap, was that a long and remarkably well thought-out post.
>
> > You would never dream (normally) of having an entity (hence table) to
> > model a collection of items
>
> Perhaps that's why I wasn't seeing what he meant. I'm so used to
> objects being over here and relational stuff being over there that I
> didn't see a conflict.
>
> > would be, I would normally define the parent object to contain a
> > collection of the child objects. But I wouldn't design a special
> > object to model that collection, I'd just use a built-in class.
>
> Hmm. I generally would have taken a generic linked-list, added some
> neat features, and declared it a new object type. But point taken.
>
> I guess it's all in how you are trying to think about it.
>
> > But to be honest, if I was using CF, OO design methodology would not be
at
> > the forefront of my mind.
>
> Me neither, at the moment. While I was very excited at first, and am
> still interested in, OO in CF, until they iron out the wrinkles in true
> OO implementation, it's going to be hard to do it right and complete.
>
> --Ben Doom
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
