mrsAngelo wrote:Actually, getInstance() should only return the existing singleton. There's no reason to lazily instantiate one.
The classic solution to create “singletons” is to instantiate them using the method get_Instance()
In this way, if I wont supply resources to the singletonWill they be a permanent part of the state of the singleton, set once and never changed?
mrsAngelo wrote:That doesn't mean much.
The environment about I am talking is a JavaBean.
There they are several classes that cooperate and it is comfortable (when it is possible) work with singleton, mainly to avoid legacy to connect objects that cooperate in situation not easily predicable .I don't do GUIs but I can't imagine any reason that a singleton would be needed for that.
They are several similar cases and I'll talk about two that are easier to describe:
1) The singleton need a reference for a component SIMPLY to show messages to the users JOptionPane.showMessageDialog(*component* , “message to show”);
2) The duty of the singleton is to refresh information on the screen, always on the same way, this work can be required many times from many objects, and the elaboration need to know the state of the JavaBeans at the moment to make the work. In this case the resource is areference to some objects that can supply the values.Refreshing has nothing to do with it. But presumably you are using it to gather information from disparate sources.
In every cases all of the classes that I realized with singletons make the same work in different situations being used by objects that not easily can have information about the instantiation (legacy) of the singleton object .If you have many different singletons doing what you stated above then I would suspect that your design is broken.