Man... you're actually completely right! I CAN instantiate all of them at startup! :-)))) (these classes must be referenced in an config file, so it's ok) Thanks!
On Wed, 2003-02-05 at 16:58, Will Hartung wrote: > > From: "Felipe Schnack" <[EMAIL PROTECTED]> > > Sent: Wednesday, February 05, 2003 4:05 AM > > Subject: RE: singleton creation (ot) > > > > I'm not sure yet of how I will do it... I would not like to > > synchronize the entire method because it'll probably be called million > > of times in my app > > Then don't call it a million times in your app. Call it once at startup and > stick it in a property in the Context. (Of course, calls to get properties > out of the context may be synchronized, I haven't looked.) > > Or simply don't synchronize it and load the singleton at startup, when you > are in more control of the environment and have confidence that a race > condition isn't happening, or at least is not important. > > The whole point of the synchronize is to serialize requests during race > conditions. Make the requests when this isn't happening and be done with it. > > The generic Singleton pattern works fine when applied genericly to generic > code. In this case you have a higher knowledge of how its being used and can > make decisions based upon that knowledge. > > Finally, as a self-rebuttal, "Don't worry about it at all unless it becomes > a problem. Early optimization is the source of many evils". > > Regards, > > Will Hartung > ([EMAIL PROTECTED]) > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Felipe Schnack Analista de Sistemas [EMAIL PROTECTED] Cel.: (51)91287530 Linux Counter #281893 Centro Universit�rio Ritter dos Reis http://www.ritterdosreis.br [EMAIL PROTECTED] Fone/Fax.: (51)32303341 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
