This kind of code is very common (or, it should be, at least):
Application.kernel = createObject("component", "com.dom.app.kernel").init();
Application.otherCFC = createObject("component",
"com.dom.app.other").init(application.kernel);
Application.thirdCFC = createObject("component",
"com.dom.app.third").init(application.kernel);
So you have your singleton instance of the kernel cfc, but you don't have
any of your other CFC's depending on it being located in the application
scope, nor being named 'kernel'. And for that matter, even that it's a
singleton.
With your setup, if you ever needed to change the variable name from the
server scope to the application scope, you'd be HOSED. Have to go change
every single CFC that uses it. But if you do it the way I outlined above,
then you only have to change one file: the file where those three lines of
code reside.
Cheers,
barneyb
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Barry L Beattie
> Sent: Monday, July 12, 2004 11:55 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] using cfinclude within components (was
> Serialization of CFCs)
>
> ahhhh...
> well, I'm sort of there. I realise that there should not be
> ANY reference to session or Application scope within the CFC
> because those shared scopes can get changed from external influences.
>
> to be honest, I thought request and server were, perhaps,
> excusable. obviously not.
>
> we're trying to introduce a "kernel" idea as a central point
> for getDSN(), error reporting, setup settings and in this
> case utils. stored in server scope, the app MUST NOT run
> without this singleton object existing.
>
> the kernel is created only in one spot and any changes have
> to go thru only one path. Every other CFC can rely on this
> kernel for what it needs on a global level. we use the
> Application.cfm to copy it over to request scope as a
> snapshot of the data at that point (any changes to the kernel
> will be picked up on the next request)
>
> is it really that bad to bend encapsulation this way? or is
> there a better way to use this kernel CFC?
>
>
> >>>> <cfreturn request.kernel.utils.arrayostructs(qry) />
>
> >>That's a violation of encapsulation, plain and simple.
> >>Something Barney and I wouldn't do
>
> understood because at that point the CFC is referencing an
> external scope. But how would be the best way to use such a
> util function? Instanciate it in the INIT() of every CFC wanting it?
>
> thanx
> barry.b
>
>
>
>
>
> > Forgive me Sean but I can't see the problem.
>
> It's one of those things that really can't be explained if you don't
> 'get' it... encapsulation is a good thing... it helps you build more
> reusable code. Referencing external stuff (like request scope or
> server scope) from inside an object is a violation of encapsulation.
> That's just a fact. Whether or not that violation of encapsulation is
> important to you depends on how much you value encapsulation. If you
> don't 'get' encapsulation then you won't value it so it's kinda
> moot...
>
>
>
> > <cfreturn request.kernel.utils.arrayostructs(qry) />
>
> That's a violation of encapsulation, plain and simple. Something
> Barney and I wouldn't do because we value the benefits of
> encapsulation but something that others would do if they don't yet
> view encapsulation as important.
>
> > but isn't instanciation of objects a performance hit?
>
> Depends. And even if it is, the performance hit may well be irrelevant
> compared to the benefits of maintaining encapsulation. It's that old
> saw about never optimize unless you know you have a problem and you've
> tracked it down to something specific...
>
> --
> _______________________________________________
> Talk More, Pay Less with Net2Phone Direct(R), up to 1500
> minutes free!
> http://www.net2phone.com/cgi-bin/link.cgi?143
>
>
>
>
> ----------------------------------------------------------
> 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]
