Hi there,
From the description you gave it did sound very much like inheritance. And that's not a bad thing, inheritance is extremely useful. Unfortunately it has some drawbacks too. Barney has covered the ground well but here is a link to an article that discusses Inheritence vs Composition in greater depth.
Cheers, Pete (aka lad4bear)
On 19/08/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
That's treading REALLY close to the edge of "proper inheritance". But
you set it right in the last paragraph: "...implements the person
interface." The catch is that behaviour can only be inherited from a
single source, but you can implement multiple interfaces. CFCs only
provide inheritance (not interfaces), so you have to be careful.
To take your example further, what if you also have Employee that
extends Person, and then one of your pesky Employees decides to take a
night class at the local CC, and suddenly needs to be converted to an
EmployeeStudent or something. Two problems:
1) you're changing the type of an entity, which means killing one
entity and creating a new one, and I've never seen a person do that
when they enroll in school.
2) you're going to have an incredibly dense (as well as impossible to
create) class hierarchy to make it work, unless you've got multiple
inheritance, which CF doesn't.
If, however, you had Person objects, and then they had a collection of
jobs/roles/tasks, two of which were Student and Employee, you'd avoid
both problems.
cheers,
barneyb
On 8/19/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Concrete approach is a perfect way to segregate customizations from base
> business logic. This is different from composition.
>
> I agree with your use of "abstract". Abstract defines an interface.
> Concrete is where you implement the interface. You should not
> instantiate an abstract class directly. Rather, instantiate a concrete
> class that extends the abstract class.
>
> I have a person "abstract" CFC that has properties like firstName,
> lastName, etc. All of the "generic" properties that describe a person.
> Then perhaps I have a student CFC that extends person. Student inherits
> all person's functionality, yet I can further describe the student in
> terms that may not apply to a person. I.E. class schedule.
>
> Person can be used as the base for any number of other person "types".
> Each person type (ie student) is a concrete CFC that implements the
> person interface.
>
> Tom
>
>
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 50 invites.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
