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]
