[PsychoCoder]

Recently I've been spending a lot of time reading on the Singleton Design Pattern and have started using it when I think it fits, like what was once a static class that is just a collection of utilities that is used many times, even in the same form. Singleton allows me to ensure that the utilities class is instantiated but once per form where it's needed.

For those who do not already know what Single is, here's a definition:

Quote

The Singleton design pattern is used to represent an object in a situation where only a single instance of that object can exist. Situations where this might arise include objects representing null or empty, centralized broker objects, centralized accumulator objects, etc.

Anyone else use this design pattern? If so what do you use it for and how do you implement it? Discuss

[markhazlett9]

Spent a bunch of this semester learning about it and implementing it in school projects. Haven't yet used it in real-world projects yet. I find it helps out my design process a ton especially when I'm doing large projects

However the ones that I used were implemented in java and not .NET.

This post has been edited by markhazlett9: 16 December 2009 - 11:15 AM

[KYA]

I know this is C# Programmers, but the most recent time I used it was when I was developing a Java DB application, I ended up making the DAO portion a static singleton object to the whole app so I could call the appropriate DB action (insert, update, etc...) from each form without a separate object for each.


Very useful/handy.


edited for typos

This post has been edited by KYA: 16 December 2009 - 11:29 AM

[EdwinNameless]

PsychoCoder, on 16 Dec, 2009 - 05:01 PM, said:

Anyone else use this design pattern? If so what do you use it for and how do you implement it? Discuss

Should probably be moved to another forum, as this is not C#-specific stuff...

I used to use it a lot, but I'm now trying to stay away from it as much as possible. If you Google "Singletons are evil", you'll find an awful lot of resources on this. The bottom line is that singletons make it hard to unit test, as they can potentially pull in tons of dependencies behind your back, or bring in resources such as database connections, EJBs, etc. which is always a pain when unit testing...

Now, there are quite a few instances where this is still beneficial/recommended to use Singletons, but as a rule of thumb, I try to avoid as much as possible. Same goes for static calls.

[snoj]

You mean something like this?

class world {
   public static List<string> arguments;
   public static bool ArgExists(string argName) { /*blah*/ return result; }
   public static string GetArgValue(string argName, int offset) { /*blah*/ return "value"; }
}

`

[PsychoCoder]

EdwinNameless, on 16 Dec, 2009 - 09:35 AM, said:

Should probably be moved to another forum, as this is not C#-specific stuff...

I know it isn't language specific but I was directing this question to the C# developers in this community so I posted it here for that reason. Now that doesn't mean someone (Such as KYA did) that someone cannot post regarding the topic, but I posted this right where I wanted it

[MentalFloss]

I use it sometimes. That pattern gets a lot of flak though... but if it fits in a spot you think it fits, use it til it stops fitting. (But then that's the problem, singletons are hard to revert out of being a singleton. Lots of code usually needs reworked)

I honestly cannot think of any recent examples of using it though. I have definitely mentally deprecated it so sometimes might really be seldom.

[eclipsed4utoo]

I use it with my Linq-to-Sql DataContext object. Linq-To-Sql does not cooperate with an N-tier architecture very well. So if I use a DataContext object in one of my data layer classes and return a "class object"(or whatever the classes are called that Linq-to-Sql creates) back to my business layer, if I need to update that object back to the database, I must use the same instance of the DataContext that retrieved it from the database. Since the instance of the previous DataContext is now gone because it went out of scope, I can't update. So I need to keep the same instance of the DataContext in order to be able to update data.

So basically, I have a "globals" class in my data layer that only has the DataContext. And in the Singleton method, I check to see if the DataContext is null. If it is, I create a new one.

Whether that's the correct way of doing it, I don't know, but it's the only way I could find to make it work.

This post has been edited by eclipsed4utoo: 16 December 2009 - 09:08 PM

[MentalFloss]

That sounds like a perfectly acceptable usage of singleton eclipsed3utoo.

[EdwinNameless]

PsychoCoder, on 16 Dec, 2009 - 06:05 PM, said:

Now that doesn't mean someone (Such as KYA did) that someone cannot post regarding the topic, but I posted this right where I wanted it

But imagine, we could have missed it!!! And you'd have missed lots of insightful and enlightened responses about other languages you probably don't care about!

[PsychoCoder]

You have a very good point there, so I'm moving this to the Corner Cubical so people who use this pattern (in any language) can chime in with their knowledge.

[Programmist]

I wouldn't call any design patterns "bad". It's all about using them when they are appropriate. If you're looking for bad patterns, search Google for "anti-patterns." You'll find plenty. Anyway, getting back the the singleton; I typically use it for certain service implementations, especially those that require a lot of resources or take too much time to instantiate. I used to roll my own using a private static instance, a private constructor, and a static "instance()" method. Now I just inject my services and let the IoC container (Spring, Guice, WebBeans, etc) handle the scope as I've declared in the configuration. Thread safety is also often a big concern for singletons as well.

[stayscrisp]

Singletons are especially useful when developing games, mostly because there are a lot of classes that only do one thing and only need one instance such as Sound Managers and Engine specific initialisation calls. It is much easier to create a Sound Manager that is a singleton and access it like so

SoundManager->Instance()->PlaySound("file");

Really nice IMO.

[Raynes]

Interestingly, Scala does not have a 'static' keyword at all. It has Singleton Objects that are used wherever a static class would be used.

[PsychoCoder]

@Programmist: Some good points there my friend. I'm not sure how they work in other languages but in C# you can make your Singleton completely thread safe.

First we need these 2 variables

private static volatile T _instance;
private static object _synch = new object();

Then in our Instance property of our Singleton we check to see if an instance already exists, if not we lock it then generate an instance, something like this

//check for an instance, if one isnt there
//then lock and create an instance
if (_instance == null)
{
	lock (_synch)
	{
		if (_instance == null)
		{
			 //do your work here
		}
	}  
}				

Just thought I'd share that.

Also, with C# (once again not sure about other languages) you can make your Singleton so generic that it can be used with any class you wish to be a singleton instance. You can do this with the following signature of your Singleton class

public abstract class Singleton<T> where T : class
{

}

I made it abstract so within the class I wish to make Singleton I dont have to do anything except make the constructor private and implement it like so

public class MyClass : Singleton<MyClass>
{

}

If I didnt make it abstract I could make the class a Singleton by adding this property

public static MyClass Instance
{
	get { return Singleton<MyClass>.Instance; }
}

I think this may be a good topic for a C# tutorial I'm thinking.