What do you think of a "global" CFC which has several standard methods for
inhertited CFCs? But I don't know if it is a good idea to inheret all CFCs
from one "application CFC"??
It isn't. Inheritance for reuse is bad. Inheritance should be reserved for "is-a" relationships and using it to facilitate code reuse like this can get you into a mess. It would prevent you using inheritance for real "is-a" relationships between these objects because you can only extend one CFC.
There are exceptions of course but you should start from the premise that it's a bad idea and really examine your classes and their relationships.
Sean,
Would one of your exceptions be the root cfc that cfcs inherit if we don't specify an extends value? If you consider the model as a collection not of objects, but of representations of objects, then it would make sense that:
truck.cfc is a
automobile.cfc is a
machine.cfc is a
cfc.cfc...or the like.
This root cfc should, then, only include that which is common to all cfcs. Perhaps utilities, like some sort of extension to the language (e.g., ListWithNullsToArray, which will use ListToArray to convert "foo,bar,,baz," into a 5 element array with elements 3 and 5 being empty strings), or abilities your particular architecture may warrant (e.g., if your architecture demands that components register themselves or check their serial number before running).
I've typically seen such Utility code bundled up on it's own, and not inherited. But this seems to make sense.
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at [EMAIL PROTECTED]
