I guess I've just always had it drummed into my head that smaller is almost always better, whether it's a Smalltalk class, a Java class, a Fusebox fuse, or a CFC. Of course, there are always exceptions to this rule, but it often seems true.
Small is also a relative term. I would say that I am happiest when my CFCs are under 500 lines. But they can run up to 1000-2000 lines. If I see a CFC that is more than about 1500 or 2000 lines, I'm going to start looking hard at that CFC because warning bells are going off in my head. Again, I'm not saying NEVER write a CFC that long, just that if you are writing CFCs that long, you should be looking carefully at them to be sure you're not diluting the cohesion of the CFC. Subclassing and/or compositing other CFCs should (IMHO) be carefully considered in these cases. The Oracle databases that we are hitting hold immense numbers of records (tens of millions) and contain upwards of 100 tables. So right off the bat we're doing lots of joins (unless we create materialized views, which we do on occasion but they eat huge amounts of disk space). On top of that, the queries are very complex, often involving numerous subqueries, inline views, conditional logic (case statements), statistics calculations (standard error and the like), PL/SQL user-defined function calls, etc. We're looking at moving these to stored procs and/or SAS scripts, which would make the CFCs simpler but basically would just move the big queries from one place to another. Also, lots of the queries are "one offs", meaning they are used in one place for a very specific purpose. So moving them to stored procs is less compelling because a primary benefit of using stored procs (reuse) is not applicable. Still, it may happen. I guess the point being, these are some of the most complex SQL statements I've ever seen (let alone written), so they tend to be very big (and not much fun to write by the way but that's just life...) Hope that sheds some light on my comments. Regards, Brian -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffry Houser Sent: Tuesday, July 13, 2004 10:55 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] CFC size I'm still not convinced that line count is an indicator of good (or bad) design. What would you consider small? 100 lines? 500 lines? Have we already defined large as 1000+ lines? Would you include "Get / Set" methods in your line count? Most of the SQL statements I've dealt with rarely go beyond 20 lines. The bulk of the "lines" are usually due to specifying each individual column returned from the query (No wildcards). I'm curious as to what sort of queries you are writing. At 10:30 AM 7/13/2004, you wrote: >That's why I said it's a "strong indicator". I also have big CFCs >(usually due to big SQL statements), but in general I'll stick by my >statement. Huge CFCs very often are CFCs that are doing too much. Put >another way: it's my opinion that most well-designed CFCs are small. > >Regards, > >Brian > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of Jeffry Houser >Sent: Tuesday, July 13, 2004 9:58 AM >To: [EMAIL PROTECTED] >Subject: RE: [CFCDev] CFC size > >At 09:23 AM 7/13/2004, you wrote: > >Unless there are really specific reasons for needing it (perhaps long > >SQL statements), if you have a CFC with thousands of lines of code in > >it, that's a strong indicator that it should be broken down. It's > >probably doing too many things. > > I don't know if I agree that "number of lines of code" is an indicator >of >poor logic / component design. It may be, it may not be; without >knowing >more details we just can't tell. > > Of the two big projects I'm working on, both have components > 1000 >lines. One on I'd say the design is suspect, on another I'd say the >design >was solid. Of course, I'm not basing either decision on the number of >lines of code in components. > > > >-- >Jeffry Houser, Web Developer, Writer, Songwriter, Recording Engineer ><mailto:[EMAIL PROTECTED]> >-- >AIM: Reboog711 | Phone: 1-203-379-0773 >-- >My Books: <http://www.instantcoldfusion.com> >Recording Music: <http://www.fcfstudios.com> >Original Energetic Acoustic Rock: <http://www.farcryfly.com> > > >---------------------------------------------------------- >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 >www.mail-archive.com/[EMAIL PROTECTED] > >---------------------------------------------------------- >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 >www.mail-archive.com/[EMAIL PROTECTED] -- Jeffry Houser, Web Developer, Writer, Songwriter, Recording Engineer <mailto:[EMAIL PROTECTED]> -- AIM: Reboog711 | Phone: 1-203-379-0773 -- My Books: <http://www.instantcoldfusion.com> Recording Music: <http://www.fcfstudios.com> Original Energetic Acoustic Rock: <http://www.farcryfly.com> ---------------------------------------------------------- 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 www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- 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 www.mail-archive.com/[EMAIL PROTECTED]
