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).

So say we had out ConfigBean we would first do something like:

application.configBean = createObject("component", "configBean").init(
/* initial values */);

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

so

thingyGateway = createObject("component",
"ThingyGateway").init(application.configBean);

Does that make more sense maybe?

Mark

On 28/10/05, Nathan Strutz <[EMAIL PROTECTED]> wrote:
> On 10/27/05, Mark Mandel <[EMAIL PROTECTED]> wrote:
> > If you are going to build an object that wraps application
> > variables... why not just store the variables inside the Object
> > itself, and just make it a singleton in the application scope and/or
> > pass it to all your other objects at startup?
>
> In order to reduce rudndant data in memory. Why should 1000 objects
> have a load of private vars, when they can all share a central object.
> Really not the largest concern in the universe, but i'm practicing in
> over-engineering ;)
>
> Of course I can't hard-code them, as things like the DSN will change
> from time to time, and I don't want to find all the CFCs that have the
> wrong one, this should be in a config file, loaded into an
> application-scoped settings object to make it as easy as possible.
>
> The singleton pattern... I'm confused a bit, haven't read that chapter
> yet. My understanding is that it's a manager for a collection of
> object instances, so if 2 people request the same object, different
> instance, it spits out 2 and may keep them in a pool. If 2 people
> request 1 object, it hands them both the same instance. Correct me
> where i'm wrong.
>
> If you like, we can go over the structure of dopefly.com, kinda what I
> have planned out, since that's basically what we're doing now anyway
> :)
>
> -nathan strutz
> http://www.dopefly.com/


--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
ICQ: 3094740


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