Whether to use static class or not

Question

Possible Duplicate:
When to Use Static Classes in C#

I will write code in which I need class which holds methods only. I thought it is good idea to make class static. Some senior programmer argue that do not use static class. I do not find any good reason why not to use static class. Can someone knows in C# language there is any harm in using static class. Can static class usage required more memory than creating object of class? I will clear that my class do not have single field and hence property too.

For further information I will explain code also.

We have product in which we need to done XML handling for chart settings. We read object from XML file in class Library which holds chart related properties. Now I have two Layers first is product second class Library and XML related operations. Actually senior programmers want independent class to read and write XML. I make this class static.

In another situation I have class of chartData. In that class I want methods like whether Line of Axis,series of chart is valid or not. Also whether color of chart stores in ARGB format or plain color name. They do not want those methods in same project. Now can I make class static or create object.

Answer 1

If your class does not have to manage state then there is absolutely no reason to not declare it static.

In C# some classes even have to be static like the ones that have extension methods.

Now if there's a chance that it requires state in the future, it's better to not declare it as static as if you change it afterwards, the consumers will need to change their code too.

Answer 2

One concern is that statics can be harder (not impossible) to test in some situations

Answer 3

The danger of static classes is that they often become God Objects. They know too much, they do too much, and they're usually called "Utilities.cs".

Also, just because your class holds methods only doesn't mean that you can't use a regular class, but it depends on what your class does. Does it have any state? Does it persist any data that's being modified in your methods?

Answer 4

Having static classes is not bad, but could make you think why you have those methods there. Some things to keep in mind about that:

if the methods manage behavior for classes you have in your project, you could just add the methods to those classes directly:

//doing this:
if(product.IsValid()) { ... } 

//instead of:
if(ProductHelper.IsValid(product)) { ... }

if the methods manage behavior for classes you can't modify, you could use extension methods (that by the end of the day are static! but it adds syntactic sugar)

public static bool IsValid( this Product product ) { ... } 

//so you can do:
if(product.IsValid()) { ... } 

if the methods are coupled to external services you may want to mock, using a non-static class with virtual methods or implementing an interface will let you replace the instance with a mock one whenever you need to use it:

//instead of:
StaticService.Save(product);

//you can do:
public IService Service {get;set;}
...
Service.Save(product);

//and in your tests:
yourObject.Service = new MockService(); //MockService inherits from your actual class or implements the same IService interface

by the other hand, having the logic in non-static classes will let you make use of polymorphism and replace the instance with another one that extends the behavior.

finally, having the logic in non-static classes will let you use IoC (inversion of control) and proxy-based AOP. If you don't know about that, you could take a look at frameworks like Spring.net, Unity, Castle, Ninject, etc. Just for giving you an example of what you could do with this: you can make all the classes implementing IService log their methods, or check some security constraints, or open a database connection and close it when the method ends; everything without adding the actual code to the class.

Hope it helps.

Answer 5

It depends on the situation when to use static classes or not. In the general case you create static classes when you do not need to manage state. So for example, Math.cs, or Utility.cs - where you have basic utility functions - eg string formatting, etc.

Another scenario where you want to use static is when you expect the class to not be modified alot. When the system grows and you find that you have to modify this static class alot then its best to remove the static keyword. If not then you will miss out on some benefits of OOD - eg polymorphism, interfaces - For example you could find that I need to change a specific method in a static class, but since you can't override a static method, then you might have to 'copy and paste' with minor changes.

Answer 6

Some senior programmer argue that do not use static class.

Tell him he is a traineee, not even a junior. Simple. The static keyword is there for a reason. if your class only has methods without keeping state - and those cases exist - then putting them into a static class is valid. Point.

Can someone knows in C# language there is any harm in using static class.

No. The only valid argument is that your design isbroken (i.e. the class should not be static and keep state). But if you really have methods that do not keep state - and those cases exist, like the "Math" class - then sorry, this is a totally valid approach. There are no negatives.