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 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Friday, August 19, 2005 2:51 PM To: [email protected] Subject: Re: [CFCDev] Better way than dao, gateway, bean: <cfquery> Exceedingly useful, and equally easy to use incorrectly. Frequently, composition is what you want when you think you want inheritance, but where you really do want inheritance, it's amazingly powerful. I suspect that if you're customizing, you might be using inheritance where you shouldn't. Typical example: if you customize a car by adding a bigger engine and new exhaust, you shouldn't be extending the Car class, you should be switching the Engine and Exhaust objects that the Car object is composed of. I tend to use "abstract" CFCs where I'd use interfaces in Java. Not so much for inheritance, but really so that I can pass multiple types as a single type (which makes the weird-ass CF type system easier to deal with). cheers, barneyb On 8/19/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > What does the group think about concrete CFCs? I use them a lot. I > create a base (abstract) CFC and extend it with another CFC (concrete) > that holds my customizations. I then instantiate and do all of > interactions with concrete CFC. The good thing is I can have as many > CFCs extend the abstract CFC as needed. This affords me to have > different "views" of the same base CFC. > > This is a very flexible solution to a lot of the issues I've seen > discussed in this thread and elsewhere. > > > 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]
