When I create utility classes I typically create a class that has a private constructor and exposes all of it's methods and properties as static. What's the best approach for this? What's the difference between the way I do or creating a static class?
5 Answers
Static classes are automatically sealed, so people can't inherit and override their behavior.
That is the only real difference (unless there is something special in the IL)
So if you use a static class, you save yourself the trouble of making the constructor private, and declaring the class sealed.
I would add, that defining a class as static, is "self-documenting" code. Users of your library will know that this class should not be instantiated, and only has static values.

- 45,915
- 17
- 113
- 134
-
3There actually is something special in the IL. Static classes are marked both abstract and sealed (which cannot be otherwise done from C#) which absolutely prevents instantiation. – Greg Beech Nov 27 '08 at 09:59
-
3Note that according to Mehrdad ([here](http://stackoverflow.com/questions/5241899/what-is-the-difference-between-static-methods-in-a-non-static-class-and-static-me/5241927#5241927)), another difference is that static methods on non-static classes cannot be extension methods. – Benjol Jun 01 '11 at 06:20
A static class can never be instantiated. No way, no how.
A non-static class with a private constructor but all static methods can be abused in various ways - inheritance, reflection, call the private constructor in a static factory - to instantiate the class.
If you never want instantiation, I'd go with the static class.
Edit - Clarification for FosterZ's comment
Say you have this utility class:
public class Utility
{
public static string Config1 { get { return "Fourty Two"; } }
public static int Negate(int x) { return -x; }
private Utility() { }
}
If another developer isn't clear on its intent, they could do this:
public class Utility
{
public static string Config1 { get { return "Fourty Two"; } }
public int Config2 { get; set; }
public static int Negate(int x) { return -x; }
private Utility() { }
/// Get an instance of Utility
public static Utility GetUtility()
{
return new Utility();
}
}
Now you have a Frankenstein class. Some of its features require instantiation and some don't. Maybe that's what you want but maybe it's not. You could prevent this with code review, but why not make your intentions explicit in code? Marking the class as static
eliminates any possible confusion. You can't instantiate a static class or inherit from it.

- 25,526
- 6
- 73
- 100
-
can you please give me a small example for this point "call the private constructor in a static factory - to instantiate the class", m finding little difficult to understand this... – FosterZ Dec 10 '10 at 05:20
-
2
-
"A static class can never be instantiated. No way, no how." - Aren't static classes intantiated once, but only once? You can even create a static constructor, albiet a parameterless one. – mark_h Sep 27 '19 at 08:29
In addition to the previous answers: The compiler won't allow non-static members on static classes and produces and error. This may help a little bit to not accidently add non-static members.

- 911
- 5
- 7
you can pass object of a class that has private constructor as a parameter to any method but you can't do the same with static class. This is the major difference.

- 31
- 1
Also I'm going to go with the private constructor never being called by the static methods. So any initialisation in there would be wasted... But that's just a theory.

- 4,327
- 23
- 25