this is probably the coolest mention yet. I write bunches of apps on an intranet. Business rules dictate that processes and such change frequently, I'm being a little funny here, but in reality stuff changes often. Hence many apps tend to have a short life span, usually the not so comlpex ones, eh? In this case why go overblown OO? After reading the 'why getters and setters are evil' stuff I realised that hey, not every app has to be super duper MVC, IVC, BED, or whatever acronym, eh? The below though got me all teary-eyed for sure, best motivation yet! danke!
Doug On Thu, 30 Sep 2004 22:23:22 +0200, Nando <[EMAIL PROTECTED]> wrote: > 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 > > At 01:15 AM 9/30/2004, you wrote: > >Steve, > > > >First, have you tested invoking or instantiating cfc's to see what the > >performance cost actually is? In my experience, and i think many people > will > >agree, the performance bottlenecks are usually at the database access > point. > >If you encapsulate your DB stuff in DAO's (the CRUD functions) and gateways > >(which return query objects) i think you'll find that your lightweight > >cohesive gateways don't cost much at all to instantiate, and they do most > of > >the front end work in most apps. > > > >If you wanna go to town tho', and generally i can't resist the temptation, > >you can instantiate your stateless gateways into a object that you store in > >application scope (i won't qualify what that object might be ... different > >apps probably could and should have very different architectures), pass in > >the dsn stuff once only, and hit your cached gateways for the rest of the > >day and night for free. > > > >But again, it's very unlikely your performance bottleneck will show up here > >under stress testing, but i like writing code like this. ;) > > > ><cffunction name="init" access="public" > >returntype="myCachedInAppScopeObject" output="no"> > > <cfargument name="dsn" type="string" required="true" /> > > <cfset generateGatewayObjects()> > > <cfreturn this /> > ></cffunction> > > > > ..... > > > ><!--- factory section ---> > > > ><cffunction name="generateGatewayObjects" access="private" > returntype="void" > >output="no"> > > <cfset setEventGateway() /> > > <cfset setFAQGateway() /> > > <cfset setFlashGateway() /> > > <cfset setImageGateway() /> > > <cfset setPageGateway() /> > > <cfset setPersonGateway() /> > > <cfset setProductGateway() /> > > <cfset setTextGateway() /> > > <cfset setUserGateway() /> > ></cffunction> > > > ><!--- EVENT GATEWAY ---> > ><cffunction name="setEventGateway" access="private" returntype="void" > >output="no"> > > <cfset variables.EventGateway = > >createObject('component','myMapping.dao.EventGateway').init(variables.dsn) > >/> > ></cffunction> > > > ><cffunction name="getEventGateway" access="public" > >returntype="myMapping.dao.EventGateway" output="no"> > > <cfreturn variables.EventGateway /> > ></cffunction> > > > >etc ... > > > >:) Nando > > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >Behalf Of Steve Bryant > >Sent: Thursday, September 30, 2004 3:48 AM > >To: [EMAIL PROTECTED] > >Subject: Re: [CFCDev] Encapsulation and Request vars (was Function > >Libraries) > > > > > >That does seem like good encapsulation. > > > >How would I go about doing that? Would I need to do that in my init method? > >If so, does this also limit my ability to use a method without first > >instantiating the component. Again, I am not married to that approach it > >just seems handy for rarely used methods in rarely used objects. > > > >If using cfinvoke as I am is a bad practice, I would certainly like to > >understand when it should be used so that I can adjust my practices > >accordingly. I would also like to understand the performance implications > >of instantiating the object every time. Am I worrying about that for > >nothing? I am expecting the site to be pretty high-traffic so I am > >abnormally concerned with performance. > > > >Thanks and sorry for all of the question! > > > >Steve > > > > > >At 08:33 PM 9/29/2004, you wrote: > > >Steve, > > > > > >Although I am not an OO or good design guru and someone might guide > > >you a better design decision however what about having all your dsn > > >variables i.e dns name, username, password etc as an instance variable > > >of a DAOConstants cfc.. For all other CFCs in your model you can > > >essentially composite this DAOConstants cfc and get those variables by > > >calling the getter method on your contants CFC. Hope it helps > > > > > >Qasim > > > > > > > > >On Wed, 29 Sep 2004 20:19:38 -0500, Steve Bryant > > ><[EMAIL PROTECTED]> wrote: > > > > I have a practical question to bring to this little discussion. > > > > > > > > I am currently coding my first site which makes large-scale (for me) > use > >of > > > > CFCs. Most of these CFCs access the database for the site. I am > >currently > > > > using a request variable to store the datasource. I am not doing this > > > > because I don't believe in the value of encapsulation, but rather > >because I > > > > can't figure out a better way to handle it. > > > > > > > > I don't want to pass the datasource in to each and every method. I > don't > > > > want to incur a bunch of overhead in getting the datasource for query > in > > > > every method. I do want to be able to invoke some methods (via > cfinvoke) > > > > without first instantiating the object. > > > > > > > > I am certainly missing some good practice of which others are aware. I > > > > would love to be enlightened. > > > > > > > > Thanks All! > > > > > > > > Steve > > > > > > > > At 07:35 PM 9/29/2004, you wrote: > > > > >You are, of course, free to do whatever you like. But encapsulation > has > > > > >a huge history of benefits and I'm afraid your opinion isn't going to > > > > >put the slightest dent in that history. > > > > > > > > > >In your example, I would argue that you should indeed be passing the > >CGI > > > > >variable into the CFC and not calling it directly. There's absolutely > >no > > > > >reason to do call it directly, the "cost" of passing it in is > >miniscule, > > > > >but the benefits of well-encapsulated code are thoroughly confirmed. > >The > > > > >same applies to calling request-scoped UDF's from within a CFC: it's > > > > >totally unnecessary. In fact, why are the UDF's in the request scope > > > > >anyway? I'd say, move them into an object and call them through the > > > > >object. If another CFC needs to use them, I'll pass in the object. > > > > > > > > ---------------------------------------------------------- > > > > 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] > > > >---------------------------------------------------------- > >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] > > ---------------------------------------------------------- > 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] > -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it? ---------------------------------------------------------- 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]
