<snip> As far as i understand, invoking a method from an object that hasn't been instantiated is totally fine if you don't need that object to maintain or guarentee a certain state once it's created. One of your concerns in the original post was "I don't want to pass the datasource in to each and every method. " ... which implies that you want to maintain state in some way. Hmmm? So you can't have it both ways. Of course, as i said, in this case it doesn't "matter" for performance, but maybe the general principle of it is nagging at the back of your mind. </snip>
You hit the nail on the head! That is exactly what I was thinking and I never even saw it. I didn't see how I was contradicting myself. I am now convinced that passing the datasource in the init method of each object is a good approach for my situation.
As for issue 2, I have made the very same case to others in the past. I don't know how I missed it in this case. I will say, in my defense that the tables being specific to this project (for the moment) did lead me to think that portability wasn't an issue. Even so, you have made your case well and I believe that I now see the error of my ways.
I think I understand the general principles that I need right now, so I will pass on the detailed explanation of your particular approach for the moment (I will likely need it later, but I have pressing deadlines).
Thank you very much for your explanations and your patience.
Ciao!
Steve =)
At 03:23 PM 9/30/2004, you wrote:
Steve,
I think the groking is just a matter of seeing how it all ties together. That example is actually pretty simple, once you understand it. It takes advantage of the fact that the gateways are encapsulated and cohesive (doing one thing and doing it well) to make the code both more efficient and organized. If you want me to walk you thru it, send me an email off-list and i will.
As far as i understand, invoking a method from an object that hasn't been instantiated is totally fine if you don't need that object to maintain or guarentee a certain state once it's created. One of your concerns in the original post was "I don't want to pass the datasource in to each and every method. " ... which implies that you want to maintain state in some way. Hmmm? So you can't have it both ways. Of course, as i said, in this case it doesn't "matter" for performance, but maybe the general principle of it is nagging at the back of your mind.
You were also concerned about the cost of instantiation, which taken together, implies that you want to know if there is a way to maintain state and reduce or eliminate the performance cost of instantiation.
I'm not great with pattern terminology yet ... but the containing object in my example (which is instantiated once into application scope) functions both as a way to maintain the state of the datasource and as a factory to instantiate and then encapsulate all the gateway objects you need in your app. So in essence, it does what you seem to be asking for.
So for your question 1), i would say invoke your method and pass in your datasource every time if you don't want or need to instantiate the cfc (instantiating gives you an opportunity to guarentee that the object is always in a valid state to function in the app ... if you don't need that, then invoking only the method is totally fine.)
And 2) ... to me the BIG benefit of encapsulation that i've come across isn't that you might want to move the application and can't be bothered to do a search and replace or change a variable somewhere. It's that you begin to think about the architecture of your apps in a different way. The small price you pay to encapsulate pays off really big down the line when you start dropping some pretty complex stuff into your app and it just ... works. It paves the way for elegant architecture. And elegant architecture functions better in a variety of very tangible ways.
Now you've gotten me all inspired ... i should get back to work. Someone's on the phone ... email me if you want me to walk you thru that code ...
ciao, Nando :)
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steve Bryant Sent: Thursday, September 30, 2004 3:31 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Encapsulation and Request vars (was Function Libraries)
Nando,
I confess that I don't fully grok everything in your email (although the follow-up email helped). It does seem, though, that I may be too worried about the cost of instantiating an object. I confess that I haven't done any performance testing. This leads me to two questions.
1) Is it ever a good idea to invoke a method from a CFC that hasn't first been instantiated? (and if so, when?)
2) I am unclear on the benefits of encapsulating the datasource for methods that are calling database tables. The database tables are specific to this project (although I admit that I might eventually generalize some of them) and the datasource is specific to database. It seems to that the benefits for encapsulation are most obvious for objects that you might want to move to different applications. I suspect that the answer is that I need to reevaluate my CFCs and make them more generalizable.
Thanks!
Steve
----------------------------------------------------------
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]
