Static classes and/or singletons -- How many does it take to become a code smell?
- by Earlz
In my projects I use quite a lot of static classes. These are usually classes that naturally seem to fit into a single-instance type of thing. Many times I use static classes and recently I've started using some singletons.
How many of these does it take to become a code smell? For instance, in my recent project which has a lot of static classes is an Authentication library for ASP.Net.
I use a static class for a helper class that fixes ASP.Net error codes so it can be used like
CustomErrorsFixer.Fix(Context);
Or my authentication class itself is a static class
//in global.asax's begin_application
Authentication.SomeState="blah";
Authentication.SomeOption=true;
//etc
//in global.asax's begin_request
Authentication.Authenticate();
When are static or singleton classes bad to use? Am I doing it wrong, or am I just in a project that by definition has very little per-instance state associated with it?
The only per-instance state I have is stored in HttpContext.Current.Items like so:
/// <summary>
/// The current user logged in for the HTTP request. If there is not a user logged in, this will be null.
/// </summary>
public static UserData CurrentUser{
get{
return HttpContext.Current.Items["fscauth_currentuser"] as UserData; //use HttpContext.Current as a little place to persist static data for this request
}
private set{
HttpContext.Current.Items["fscauth_currentuser"]=value;
}
}
