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