I agree that you can't optimize code by minimizing the number of characters. I still remember getting only above average marks in college for a nice, clean, well written piece of C to solve a problem in 50 well commented lines. I was "beaten" by a guy that wrote an extremely terse single line recursive expression (it was pretty smart, however) that even the lecturer couldn't figure out but that passed all of the test cases.
Clearly that is not a good approach, but looking at typical OO code with reams of similar code repeated across potentially hundreds of entities, that does not seem a good approach either. In my previous program, if I wanted to change how a record was saved across all business entities, I went to one script, changed the clearly commented, simply parameterized SQL and was done. Lets say you wanted to: - Add a meta property (say DateTimeLastUpdated) to every insert and update - Change the flow of handling your forms to reflect a more sophisticated validation approach - and add a simple switch to allow each screen to decide whether a successful add should be followed by a list with a success message or the redisplay of the form to "add another". Now assume you have a couple of hundred business entities With a well thought out parameterized approaches you could easily make all three changes in 20 minutes. I guess you might possibly be able to do the same using search and replace on a traditionally architected OO platform, but I wouldn't want to try it myself . . . Conciseness does not inherently obfuscate code. It is a matter of the elegance of the parameters and model that you choose. That's the difficult part! Bets Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RADEMAKERS Tanguy Sent: Tuesday, May 30, 2006 1:37 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] FW: Maintainability vs. reusability? >-----Original Message----- >To potentially oversimplify the issue, I'll go out on a limb and say >that unless you *are* using something that generates your DAO(s) for >you, having a single generic DAO seems like a maintenance nightmare to >me. I envision (particularly with your last point below) a maze of >conditionals or switches that to me only gains you the ability to say >"but I only have one DAO!" That's one big rule of thumb for me--if the >conditionals start becoming overwhelming, then you're trying to do too >much in one place. Just to add my 0.02$: the biggest usual headache in code maintenance or debugging (which are often the same thing) is figuring out what change needs to be made where, as opposed to actually making that change. You *may* occasionally immediately see that you need to make a relatively simple change across a vast vast number of files, but that's pretty rare: you will usually be staring at the code with a blank look on your face, trying to figure out how it's supposed to work, why it isn't working, and what you need to do to change that. Usually with the boss and or the client breathing down your neck. Moral: keep your code as simple as you possibly can and never do something clever for the sake of being clever... especially if it makes the code harder to understand. As much as possible, two peices of code that solve similar problems should use similar solutions, so that time spent understanding one of them pays off in understanding the other. In short: optimize for readability, not writeability, because you will read your code much more often than you will write it. To get back onto the topic at hand - many small, simple, and similar DAOs are easier to understand than one big "God" DAO - especially if the relationship between a business object and its DAO is very easy to grasp (naming convention, packaging, etc. If you use ColdSpring, even better). If you find that you are copying and pasting large blocks of code between all of your DAOs then there are solutions like inheriting from a BaseDAO or just cfincluding the common code which can help you out /t ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
