> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sean > Corfield > > It's entirely personal - CF > > makes me repeatedly flip in and out of object-think > > Why? Let's try to get to the bottom of that. >
OK. Stop me if it gets boring. My fixed mental model is "everything is an object". I can write (and have done so) object oriented code in Pascal, CF 4.0, perl and (yes, Tom), macro assembler. Where the language features aren't there to help out, they can be simulated or worked around - but this is harder, more error prone and usually slower than when they are. It also means that I have to remember how the workarounds work - the mental model is more complex and less consistent. So, in CF: 1. Classes aren't objects. This can be worked around by creating a separate CFC, an instance of which will act as the class object. In CF it seems to be common practice to put whole-of-class methods and data into service, manager and gateway objects which therefore act in combination as a class object. Service objects I've seen often provide whole-of-class methods for more than one class, as well as logic spanning classes. The relationship between the class object and the instance object can be managed by convention. There are some situations where frameworks instantiate business objects where I was stumped as to how to cleanly tell the instance about its related class object, but this is no doubt just lack of ingenuity. 2. Query recordsets aren't objects. Worse, they are a second interface into the same data that's already abstracted by my business objects. Peter Bell's IBO is a nice workaround. The more common approach is to just work in the two modes - access instance data and behaviour via method calls for individual objects, direct query field access for record sets. In this second approach, you just have to remember that if you need to put complex behaviour in a getter (e.g. do an on-the-fly data migration for backward compatibility) you need to duplicate that behaviour in a SQL view and then base your query on the view rather than the base table. This is all OK, but it nibbles away at the edges of encapsulation and DRY, drops me out of object-think and into thinking about how the plumbing works, and it means I have to remember all this or (much worse!) teach it to a junior programmer. By now, you're probably aghast at the thought me teaching anyone anything! At the end of the day, I'm commited to learning the workarounds, and (I think) well on the way to being comfortable with them. I just thought Gilad's article was interesting. Jaime Metcher You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
