Re: [CFCDev] Generic Beans (was: LTOs (was: Form Validation))

[Peter J. Farrell]

Dave Merrill wrote: What do you think about generic setValue(value_name, value, expected_type) and getValue(value_name) methods? A bean explicitly maps out it's purpose.  Using a generic type bean moves the uniqueness as well as the responsibility of that object into the calling code.  A generic bean is no longer a discrete object and no longer represents the true nature of your mode.  If I received legacy code like this, I would have to look through thousands of lines of code just to see what what this generic bean is doing instead of firing up the cfc explorer to see what it actually does. I have a generic errorHandler which uses setError(errorCode, settingObj, fieldName), getError(errorCode), hasError(errorCode) and etc.  This is a great way to use generics as I couldn't possibly have all the possible accessors for the errors in my application in the errorHandler.  The setting object controls the error codes getting set and thus has the responsibility of the errorHandler.  I usually pass in an init()'ed errorHandler on my bean's validate method, pass it back out, call hasErrors() [boolean] and either send the bean on or repopulate my form with the errors [my errorHandler only has error codes - the errorMessage class takes care of translating the codes into things more user friendly - this separates the actually user message from the model and into an object more akin to a special "View"]. I'd see a lot of benefit to individual set/get methods if we were in compiler-land, where the calling a nonexistent method was a compile-time showstopper rather than the run-time error it is in cf. It would be much harder to ship code that was broken on that level. But since that's not current cf reality, IMO it's much harder to justify the purpose of each identical basic getter and setter. True, it would be hard to ship code that is broken.  I honestly believe that is there was a better way than using getters/setters it would have made them a "legacy" method of OO programming by now. I have three goals when I code: 1.  Write code that accomplishes what is supposed to accomplish in the most efficient and concise manner. 2.  Write code that shows/demonstrates its' exact purpose by using best practices and precisely written comments/hints. 3.  Write code that could be easily maintained by someone other than myself. I think that a generic bean would be hard to maintain citing that "generic makes it generic" - it no longer explicitly shows its' purpose in your model and moves the identifying parts of your bean into the calling code.  Secondly, your bean will have to spend more time resolving arguments and less time doing what it supposed to do.  I find this to be an unnecessary waste of processing time.  The actually savings are probably hard to prove - but I'm sure an application under heavy load would show it more. To quote Bill Rawlinson: "Don't let seeming redundancy and tedium turn you away from using discrete objects to represent your model."  I'm glad that you are challenging your programming skills and exploring other options as that is the only way to keep things moving forward instead of stagnant - otherwise we'd be programming in ColdFortran! Best, .Peter P.s. For anybody who has programmed Fortran...luckily my exposure is limited to my father's Fortran programming in the 70's. "GOD is REAL (unless declared INTEGER)." -- Peter J. Farrell :: Maestro Publishing blog :: http://blog.maestropublishing.com email :: [EMAIL PROTECTED] Create boilerplate beans! Check out the Mach-II Bean Creator - free download. http://blog.maestropublishing.com/mach-ii_beaner.htm Fatal Windows Error 039: Cray not found - System Halted. -- ---------------------------------------------------------- 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). 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/cfcdev@cfczone.org