> I could see the genericDAO scheme working if there was an argument on > the create method that required an object that implemented a > fictitious interface dictating that that it only took objects with a > getConfig() method.
okay im not really getting it. the 2 scenarios are: 1. function has fully declared arguments and will throw an error if passed data is wrong type/required. Rules for wrong type/required are hardcoded. Limited re-use of CFC. 2. function has no declared arguments and will throw an error if passed data does not match the CFC config. Rules for correct data are dynamically assigned (or inherited) from another object and it can be re-used. So the main issue is that the rules are dynamic? Option 1 means that you must write and maintain all insert/select/update/delete SQL for your app? Is that correct? OK, its been a while since I went to school, and im fully prepared to be wrong, but option 2 uses Polymorphism, option 1 doesnt? "A bad solution would be to define a set of interfaces, one for each type" http://www.javaworld.com/javaworld/javatips/jw-javatip30.html -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joe Rinehart Sent: 27 January 2005 17:05 To: [email protected] Subject: Re: [CFCDev] Composition and SQL > Surely if the arguments are named,typed and/or required, then the outside > world needs very in depth knowledge of what to pass? unlike in my scenario? (Keep in mind that this is all my opinion, and that I am still rather new at this as well.) The outside world knowing what you need to pass is fine and dandy. That's interface knowledge - knowing the "outside" of the object and how it interacts and passes messages about. Interface knowledge is a good thing - it implies encapsulation of functionality. In your scenario, the interface to the method, because it doesn't use cfargument, takes anything. The outside world has to somehow "know" what the internal guts of the method are going to want, and instead of discovering it through a cfargument'd interface, it just somehow "knows." That knowledge is a coupling in which the outside world must therefore know something about the implementation that takes place inside of the method, and implementation knowledge is what we're trying to avoid through functional encapsulation in the first place. I could see the genericDAO scheme working if there was an argument on the create method that required an object that implemented a fictitious interface dictating that that it only took objects with a getConfig() method. -Joe -- For Tabs, Trees, and more, use the jComponents: http://clearsoftware.net/client/jComponents.cfm ---------------------------------------------------------- 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]
