In any case, it is challenging to listen in and try to understand when the guys that know their stuff start debating "higher level" OO, higher level for this list anyway, even if the original poster is just getting their feet wet. At the very least, it gives me an insight that there's a lot to learn here. I appreciate being exposed to things i don't understand - yet. And i would assume that most programmers do, otherwise they probably wouldn't be programmers!
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sean Corfield Sent: Thursday, April 07, 2005 3:34 AM To: [email protected] Subject: Re: [CFCDev] Question on class / subclass How complicated can we make things? Didn't we just have the discussion about over OO-ing things recently? :) On Apr 6, 2005 11:36 AM, Jerry Ela <[EMAIL PROTECTED]> wrote: > Rather than creating an unitiailized car object and passing to the DAO > to get initialized, have the DAO initialize and return the car of the > correct subtype. This is the generic "right answer" to Jason's original question about instantiating the right type of object from the database. > Also rather than have the calling program ask the > object if it is a truck to know if it can tow a boat, ask it if it can > tow. After all some cars can tow boats and some trucks can go fast, and > those capabilities should be encapsulated in the object. As Roland observes, you will probably have an arbitrary number of capabilities added over time and you might not want all of these in your base class so that you can ask these questions. His suggestion of roles is a good one (I first saw it in CF in one of Hal Helm's newsletters, I believe). It's a pattern with a name... I'd have to look that up. However, if all you want to do is find out whether an object can be asked to do something specific, you can take this quick and dirty approach: <cfif structKeyExists(myCar,"towBoat")> <cfset myCar.towBoat()> </cfif> Then any class that implements the method can be used... I'm not saying it's a good technique but it's a lot less work than adding roles. What's 'right' is hard to tell but think about the context of your problem and see just how much work you really need to do to solve your problem. Are you really going to have an arbitrary number of car classes? Are you really going to have an arbitrary number of optional capabilities? Is inheritance even the right model for your problem space? If you adopt the programming-by-contract style that interfaces imply - even in the absence of interfaces - you might not even need inheritance (just a few classes that have similar APIs). -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- 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). 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). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
