Singleton Pattern

Reply

hannes replied on 05-19-2005 7:40 PM

rated by 0 users

Cyrus Crypt wrote:

I think this is a good example of Singleton vs Static.  Cache cannot be static as the value is not known until runtime, yap?

I wanted to argue that this is what Singleton Pattern comes down to... but I created only a property instead of class for allowing access to the instance. Yes the value is not known until runtime because it can expire at any time.

Cyrus Crypt wrote:

Hannes, like to understand under what context is this "cache" being used.  What type of cache is being shared by every user?  My impression is that every user usually has a copy of their own cache (in context of web app, of course)

HttpContext.Cache is simply a dictionary of values, shared over the application (server-side). (see the thread that icelava created). There are other types of cache for web apps, but they don't come into play here.

The thing is, using the Cache dictionary in order to retrieve the single instance, is not important. But, the fact that this single instance is recreated on demand through the single access point, as the Singleton pattern prescribes, is important.

In this example, the creation of a new instance is necessary after it is removed from the cache. This can happen when the server runs lows on memory, or when the application explicitly removes it because it wants to force recreation.

In the other examples, there was just a static reference to the single instance stored inside the Singleton class... but no hint was given to the possibility of this static reference being changed by some outside influence.

Reply

Firedancer replied on 05-19-2005 10:29 PM

rated by 0 users

icelava wrote:

Firedancer wrote: As for all the debates, I still don't know whether which of the methods I posted earlier is correct. Perhaps a point that was hinted but never explicitly highlighted: do you want whatever that object contains to remain throughout from start to end of application life? Static instances die with the application's end, a singleton can be destroyed as and when you need to.

I would like the Hashtable in my class to live for the entire application lifetime. I won't be clearing it. So static is better?

Reply

pvijayaramaraju replied on 09-14-2006 1:44 PM

rated by 0 users

I will give you another implementation extracted from Scott meyers More efective C++.

public class MyClass
{
  friend MyClass CreateInstance();
 private MyClass();
}

MyClass CreateInstance()
{
 static _Instance;
 return _Instance; 
}

This implementation is quite famous in C++ circles and is called the scott meyers method.

I have never come across a book or an article which gives a recommended implementation. will you give me the link.

My Understanding is that a design pattern emphasis more on the intent rather than the way it is solved and its implementation. design patterns are supposed to be independant of languages and the various ways you can implement it are due to the features provided by the language. which ever way you implement it is the same design pattern.

ice lava wrote:
A singleton pattern, despite its name, has scalable limit to the number of simultaneous objects running around

This is wrong. it was never the intent of the pattern to support multiple objects. Though you come across such scenarios as limiting multiple instances of the class. I did some time back ead an article where they gave this another name "Multiton".

There is also a pattern called pool though these do not form a part of the basic 24 GOF Patterns.

Interesting problems though they should  have been addressed the Singleton pattern never addresses.

1) Who destroys the singleton. Most people are of the view that singleton never need to be destroyed but still.
2) When you have multiple Singleton's who are dependant on each other How are we going to manage the construction of singletons. Since the order of construction might be important.
3) what is the best way we can extend a singleton ( Inheritance ???)
4) Singleton is one of the patterns that goes against good OOP principles

is anyone interested in discussing these issues?

Reply

tuono replied on 09-21-2006 3:00 PM

rated by 0 users

public class MySingleton
{
    private static MySingleton instance;
    private Hashtable stuff;

 
    public MySingleton()
    {
         stuff = new Hashtable();
    }

    public static MySingleton CreateInstance
    {
        if(instance == null)
            instance = new MySingleton();
 
        return instance;
    }

 
    public Hashtable GetStuff() 
    {
        return stuff;
    }


}

doesn't this allows an inexperienced user from doing this

MySingleton newSingle = new MySingleton

and that wld violate the singleton principle, guess better to make the constructor private instead right?

Reply

cruizer replied on 04-10-2008 12:22 PM

rated by 0 users

if the singleton simplifies things, i'd use it. most of the time though, singletons hinder testability and makes certain code tightly-coupled to the underlying implementation of the singleton. in these cases i just use the "just create one" 'pattern'...

http://butunclebob.com/ArticleS.UncleBob.SingletonVsJustCreateOne