With CF and it's lack of static methods and fields, you can't really do an encapsulated singleton. The simple way with CF is to just instantiate your singleton in your application initialization code (which should never run more than once), and never do it again. The downside to that is that you have to instantiate EVERYTHING as part of app initialization, which isn't necessarily a good thing. Instead, you can instantiate a manager that you can request a singleton from. That manager ensures that it never creates two copies of a singleton, but you still have the problem of duplicate singletons if you somehow create duplicate managers.
I prefer the latter mechanism, in general, because I think it's cleaner. cheers, barneyb On Apr 8, 2005 8:54 AM, Ken Dunnington <[EMAIL PROTECTED]> wrote: > So when you create your object, you have it check for an instance of > itself in the local scope, and create a new one if one doesn't exist > and pass it back? For some reason, it isn't quite 'clicking' with > me... If you use createObject in your application to create an > instance of the singleton class, how do you prevent another > createObject call from creating another, unique instance of the class? > Or can you only ensure there's only one instance per scope? Maybe it's > the fact that CF makes us use a pseudo constructor that's throwing me > off... -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 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]
