Yes, those are valid concerns, but I have to assume that employee turnover is minimized, and that future hires will at least be semi-competent. If I can't assume that (regardless of whether it's true in every instance or not), I sure don't want to have that company as a client. Consequently, I'm intentionally dismissing as irrelevant the fact that it takes at least half a brain to follow through complex code. And that goes for any code organization style, not just OO.
Where OO shines (at least well-designed OO) is with readability across abstraction. Here's an example: <cfset productList = application.productGateway.getProductsInCategory(categoryID) /> That's pretty damn clear what it does, even though you know nothing about how it does it. I'd argue that it's easier to read that an inlined SQL statement, though not by a huge amount. If Joe Developer needs to CHANGE the query, then yes, he's going to have to know what the 'application.productGateway' variable is a reference to and where that CFC resides on the file system, but that's not so hard to figure out. And that's ALL he has to learn about the app to fix this problem, because everything is all encapsulated. And better, if Joe makes the change to the CFC, the rest of the app will be magically updated. Can't do that with inlined queries. While we're at it, I have to contrast this with a CFINCLUDEd query file: <cfinclude template="qry_getproductsincategory.cfm" /> This is very difficult to read, though it is much easier to find the raw SQL if you need it. In particular, you have no idea what variables the template might use, and you have no idea what the recordset will be called after it's retrieved UNLESS YOU ACTUALLY OPEN UP THE FILE AND LOOK. I'd trade the ease-of-access to the SQL for the reability any day of the week, with no hesitation at all. And yes, this coming from a huge Fusebox proponent, but you'll never see a qry_ file (and very few act_ files) in my FB apps, instead you'll see CFCs. cheers, barneyb On 8/18/05, Munson, Jacob <[EMAIL PROTECTED]> wrote: > Ok, I totally get your point, and agree. > > So 5 years later you are gone, and your client hires someone new to fix > something in your code. He finds the directory where it all lives and > starts exploring. He decides to do a text search for a string on the > problem page, because he doesn't know how else to find it. He opens > the CFM, hoping to find the offending query, only to discover it must be > in one of the 40 invoked CFCs on the page. The story could go on from > there, but the point is that there is going to be a large learning curve > for OO that is taken out to its fullest 'beauty'. 3 weeks later he > knows and understands the logic behind your application, and why it > takes 5 different files to do a select. > > Ok, so I may be exaggerating with some of the numbers here...I tend to > be a bit over dramatic. ;) > -- 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]
