In the CF world I'd say the same would apply (just not the preloader).
On 10/28/05, Nathan Strutz <[EMAIL PROTECTED]
> wrote:
Thanks everyone for formalizing a definition for me of what I've been
doing for years. It's actually not as formal as I was thinking.
Now I don't really have a problem with singletons, especially for
application settings. That's what I've been doing for a long time now.
The problem I have, is just, why would I need to do that, when, in
java, you can reference a static variable from a static object, just
like calling application.variable from a CFC in cf.
Yes, the singleton pattern is the way around it, but come on, it's
built in to the system that you don't really need this. I'm not saying
i'm going to change all my code or my style to reference static vars
or pull from the app scope, and yes I'll favor encapsulation, if only
for the fact that it 'feels' right, but really, is encapsulation that
precious?
-nathan strutz
http://www.dopefly.com/
On 10/28/05, Nando <[EMAIL PROTECTED]> wrote:
> Singletons have lots of advantages. Performance is a main one. Here's the
> basic idea:
>
> <cfif NOT StructKeyExists(application, "MessageService")>
> <cfset application.MessageService =
> createObject('component','MessageService').init() />
> </cfif>
>
> Here's the right way to do it, to make perfectly sure 2 near simultaneous
> requests don't sneak thru:
>
> <cfif NOT StructKeyExists(application,"Factory")>
> <cflock name="factoryLock" Timeout="10" THROWONTIMEOUT="No"
> Type="Exclusive">
> <cfif NOT StructKeyExists(application,"Factory")>
> <cfset application.Factory =
> CreateObject('component','Factory').init(application.Settings) />
> </cfif>
> </cflock>
> </cfif>
>
> First, you can use them to calculate, store and encapsulate data you need
> for the whole application in memory. Do the work once, hold it in memory,
> and access it via a method in the singleton.
>
> Second, you can use a singleton as warehouse for instatiated "service"
> objects that are maintained in memory for the whole application. A service
> object being one that doesn't need to maintain state for individual users.
> Gateways are a good example. Instatiate the gateways you need to get the
> display data you need into a singleton, and CF has all the queries (SELECT
> field1, field2, ... FROM tbl3 WHERE ...) it needs held in memory for
> immediate access. That seems to speed things up when you've got a complex
> page to render.
>
> Third, you can pass that singleton into other objects when you instantiate
> them, so other objects can use it. That's passed by reference in CF, so it's
> not another copy. There's an example of that above.
>
> Fourth, you get to REALLY ENJOY over-engineering your apps, instead of
> feeling a little guilty about it. And one day, when it's all actually REALLY
> needed, the outer corners of your lips will curl up in quiet satisfaction.
>
> >-----Original Message-----
> >From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]]On
> >Behalf Of Nathan Strutz
> >Sent: Friday, October 28, 2005 5:49 AM
> >To: [email protected]
> >Subject: Re: [CFCDev] public static final and "precious" CFC
> >encapsulation
> >
> >
> >On 10/27/05, Mark Mandel <[EMAIL PROTECTED] > wrote:
> >> Ah.. I think I see where the confusion lies.
> >>
> >> A singleton pattern basically just means that there is One and Only
> >> One of a given object at any given time. (Kinda like monotheism).
> >
> >Yeah, hence the term, i get that. np.
> >
> >>
> >> So say we had out ConfigBean we would first do something like:
> >>
> >> application.configBean = createObject("component", "configBean").init(
> >> /* initial values */);
> >
> >Yes, got something like that. I'm ok there, minus the m-g nomenclature.
> >
> >
> >> (or you could use some sort of manager to ensure objects are singletons).
> >>
> >> Then when you create your other objects, you would then pass in the
> >> configBean instance stored in the application scope -
> >
> >Yeah... so every object gets my config bean. That's what this whole
> >post is complaining about.
> >
> >>
> >> so
> >>
> >> thingyGateway = createObject("component",
> >> "ThingyGateway").init(application.configBean);
> >>
> >> Does that make more sense maybe?
> >>
> >
> >Yeah, i mean, that's exactly what I'm doing. I've got a 'thing
> >manager' that spits out, in this case, blog entries. I guess the
> >difference is I should have it spit out _all_ my objects, including
> >the blog entry singleton... well, except there's a different config
> >bean for each blog. So I shoul come up with some sort of lazy loading
> >thing (or, i know, use someone else's). That's cool i guess. Cool
> >enough. So that way it somewhat automates the passing of my static
> >final app vars. ok, i can dig it.
> >
> >So the singleton pattern... I know i should find some reading
> >material... The idea is, it just makes sure everything that comes out
> >of it has an instance of the config bean? Are there any other
> >advantages?
> >
> >thanks
> >-nathan strutz
> >http://www.dopefly.com/
> >
> >
> >----------------------------------------------------------
> >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).
> >
> >CFCDev is supported by New Atlanta, makers of BlueDragon
> >http://www.newatlanta.com/products/bluedragon/index.cfm
> >
> >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).
>
> CFCDev is supported by New Atlanta, makers of BlueDragon
> http://www.newatlanta.com/products/bluedragon/index.cfm
>
> 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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
--
John C. Bland II ----------------------------------------------------------
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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
