well what we have found after much debate (its like an arguement over which
came first, chicken or the egg) we have concluded that with CFMX you
effectively most of the time will at some point do the whole
parent.child.sibling object realationship...
ie in my example i went:
person.shopcart.method() to keep track of a persons interactions with a
specific type of shopping cart.
Why Would i Do that?
Well, in reality the difference between a Wishlist shopping cart and an
normal shopping cart, is the end "checkout".
So in order to track both a Shopping Cart and a Wishlist Cart, typically in
pre-CFMX you would most like have two session variables or something along
those lines.
Through my evil plan, i basically went down the road of saying well this
person can have two objects that are the same but in reality have different
properties. So i would state:
person = createObject("component", "comp.qldhol.customer");
person.shopcart = createObject("component", "comp.utils.scart");
person.wishlist = createObject("component", "comp.utils.scart");
This would still allow me to utilise the power and functionality of my
shopping cart without having to do much work or even less work then i
normally would in previous versions of CFMX.
BUT
One can then argue that why associate the shoping cart with the person
object? why not do this:
person = createObject("component", "comp.qldhol.customer");
shopcart = createObject("component", "comp.utils.scart");
wishlist = createObject("component", "comp.utils.scart");
Similiar concept, both would achieve the same result and yet which is the
cleaner and most effecient way? One could argue that if you wanted to assign
some of the "customer" logic into the scart.cfc, you could use the
this.scope to handle various properties or method calls, but if you do it
the second way you would have to actually reference the "customer" through
normal means (ie not using the this.scope)
am i making sense?
As stated earlier CFMX eventually does require a baselevel parent, in that :
session.person = createObject("component", "comp.qldhol.customer");
session.person.shopcart = createObject("component", "comp.utils.scart");
session.person.wishlist = createObject("component", "comp.utils.scart");
or
session.person = createObject("component", "comp.qldhol.customer");
session.shopcart = createObject("component", "comp.utils.scart");
session.wishlist = createObject("component", "comp.utils.scart");
I can see already a positive use for the second option, in that say you wish
to blow the entire persons movements away and restart them? ie lets say for
aguements sake that a UNO happens (Unidentified Net Occurence), and you need
to restart that persons session, you could then basically kill the "Person"
object (load rilfe and shoot him) which effectively will kill both the
shopcart/wishlit away in one full swoop.
If you tried to do it with the second option, you would have to kill each
object individually?
Not just kill, but even saving of information?
CFC are fun eh :)
Scott
"Nathan Wheat" <[EMAIL PROTECTED]> wrote in message news:22112@cfaussie...
You don't really have to do anything! :)
But to answer the question: In your example, you might have a mammal. Then
a cat is a special kind of mammal - so the mammal->cat is a specialisation,
or sub-class type relationship (extends parent).
The collar, on the other hand, is not a special kind of cat. A cat may have
a collar. This is an object-level relationship (collaboration). I would
call this an "association" because both cat and collar can exist by
themselves. You might have methods in each so that the objects can talk to
each other. You might make the association through some intermediate
transaction object to represent the cat "wearing" the collar... But that's
for another day....
A leather collar is a special kind of collar, so this is another
specialisation (sub-class/extension).
As for cow... What the? You might associate a "leather" object with a
particular "cow" if you really needed to know where a piece of leather came
from... But then again, the cow's dead so I'm sure no one really cares!
Being completely abstract, this might be some form of association - but in
the real world, you have to have some kind of reason to associate two
things, I can't see a reason here.
In your original example, it's probably more correct to introduce some more
objects. You might give a "person" a role such as "customer" (as opposed to
"administrator"). You would probably create a "shopping transaction" which
facilitates a person/role interacting with a "shopping cart" through "items"
(stores the items, has a sub-total, etc). The shopping cart knows what
functions it can do, but perhaps isn't the best place to keep track of what
a particular person is doing.
A lot of object modeling is to do with personal choice, and what the
application is really trying to accomplish. I completely recommend
"Streamlined Object Modeling" (Nicola, Mayfield, Abney). I just finished it
and it's a damn good book. But only some of it can really be appropriately
applied to traditional CFMX, as Gary suggested.
Nathan.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Scott Barnes
Sent: Tuesday, 21 January 2003 4:53 PM
To: CFAussie Mailing List
Subject: [cfaussie] Re: CFC Development
Q. In OOP do objects HAVE to have cascading relationship
ie.
Mammal --> cat --> collar --> leather --> cow
Scott.
---
You are currently subscribed to cfaussie as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
