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]
>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]


Reply via email to