Barney, here's the thing i'm not sure of. And i really mean that. Would you call it a Factory if it *contains* stateless instantiated objects (in application scope) and makes them available to the rest of the application, but didn't actually instantiate them? Or a Service? I was thinking that's a Service, hence i called it a DaoService, because it merely contains the instantiated objects and exposes them to the rest of the app to use.
I could design the Factory (the Factory being a singleton in application scope) to instantiate the DAO's into it's own variables scope, rather than returning them directly, and let the rest of the app access them via getters. But then the cohesiveness of the Factory breaks down and it's less reusable. So i'd rather pass Factory into Dao[Service?Manager?Component?WhoAmI?] so that Factory can do it's specialized thing and the Dao[Service?Manager?Component?WhoAmI?] can just do its specialized thing. Irrespective of the communication difficulties that occur because of the terminology, i find it very important how i name things in an application. Similar to naming variables very clearly. It really helps me understand what's going on. As a more personal aside: I'm having trouble keeping up with all the things i've got to learn while at the same time keeping up with all the work we have, and some of them, like double entry accounting and italian, have nothing to do with CF! So sorry if i seem a little slow to catch on sometimes. ciao, Nando >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of Barney Boisvert >Sent: Tuesday, November 15, 2005 4:47 AM >To: [email protected] >Subject: Re: [CFCDev] Factory Pattern - yes this IS about Factory >Pattern! > > >Not to jump down your throat, Nando (though I know you were indirectly >referring to me about doing it ;), but I do have to disagree on some >level. > >I'll certainly agree that a lot of the terminology is confusing, but >that's the case in any complex field. I surely don't consider medical >or legal terminology even remotely sane, but to the professionals in >the field, there's a need for the complex nomenclature. The same >thing goes in programming. > >You say service, I say factory. Suddenly we can't communicate without >a Nandolian-Barnese dictionary, and that hurts us both. And heaven >forbid we want to talk to [fictional] John, who calls them managers. >Now we need three dictionaries. > >So there's a very good reason to have a standardized nomenclature >within a community. Regarding design patterns, I think that pretty >much anyone will agree that if the GoF book speaks on the matter, it's >the authoritative source. For other topics, things are less clear, >but there is almost always an accepted lexicon. > >In that vein: > >An object whose sole purpose is to create other objects is a factory >object, not a service or a manager. >An object whose sole purpose is to expose discrete bits of >functionality through a formal API is a service object. > >A pedantic rant, to be sure, but it's not without value, because it >facilitates easier pursuit of the non-pedantic aspects of what we do. > >cheers, >barneyb > >On 11/14/05, Nando <[EMAIL PROTECTED]> wrote: >> >> Mike, >> >> I enjoyed reading your posts this morning, especially the one about the >> throngs of bank customers meeting in the road. >> >> It's hard for me too. Someone will say, for instance, that a >Service is X. >> Then someone else will say that a Service is Y and that X is a >Manager. Then >> someone else will say that if you are using Managers in your model, you >> don't understand OO design very well. Then Joe gets around that in >> Model-Glue by calling them Controllers, and i think to myself, "Gee, that >> was clever!" ;) >> >> I'm going to call it a Service. Think of the guy in the truck selling hot >> dogs to the throngs of bank customers crossing the road. That's >a Service, >> right? >> >> Here's what i've done, in case it's of any help. >> >> In Application.cfc/m instantiate Factory as a singleton. Then >have Factory >> make you instance of DaoService. When it does, pass the instance of the >> factory into it, using "this". >> >> in Factory: >> <cffunction name="getDaoService" access="public" returntype="DaoService" >> output="no"> >> <cfset var DaoService = >> createObject('component','DaoService').init(this) /> >> <cfreturn DaoService /> >> </cffunction> >> >> In Application.cfc/m, or wherever actually needed. >> (adjust as necessary) >> <cfif NOT StructKeyExists(application, "DaoService") OR >StructKeyExists(url, >> "reinit")> >> <cfset application.DaoService = >> application.Factory.getDaoService() /> >> </cfif> >> >> >> In DaoService's init method, you'll set the Factory instance you >passed into >> DaoService to variables scope so you've got ready access to it, and then >> from within DaoService, have factory make all the Dao's you need and set >> them to variables scope as well. >> >> Then you'd access them using public getters. For example: >> >> application.DaoService.getSomeSpecificDao().create() >> application.DaoService.getSomeSpecificDao().read() >> >> I've used this approach to instantiate Gateways into a GatewayService for >> front end queries. It seems to perform very well, even on views that use >> many queries to render the page. >> >> I'm not suggesting that you specifically use an object called >DaoService - >> btw. It's just to demonstrate. >> >> ciao, >> Nando >> >-- >Barney Boisvert >[EMAIL PROTECTED] >360.319.6145 >http://www.barneyb.com/ > >Got Gmail? I have 100 invites. > > >---------------------------------------------------------- >You are subscribed to cfcdev. To unsubscribe, send an email to >[email protected] 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/[email protected] > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected]
