When to go for static classes?

Whenever I code a solution to something I tend to either use a lot of static classes or none at all. For example in a recent project I had to send a class with some string/bool/datetime data through a number of hoops and the only thing that wasn't static was this data-holding class. Everything else 开发者_如何学JAVA(3 pretty hefty classes with different processing responsibilities) were static.

I think what I'm asking for here is some input on when (and why) I should avoid using static classes for these "process X, output Y" cases. Is it ok to always use them as long as they work or am I shooting myself in the foot concerning scalability, plugin-support etc?

I hope this is an OK question to ask here. I'm not asking for an argument concerning whether or not static classes are "better" - just input on when I should avoid using them.

Most of the code i write:

• Uses dependency injection/IoC
• And needs to be mockable/testable

So i just use objects for almost everything.

I do still use statics for things like:

• Extension methods
• Constants
• Helper/Utility methods (pre extension methods)
• operator methods

Still the two questions remain a bit the same. My main concern on static classes is inheritance and accessability.

When using a static class (public in the worst case), everyone is able to access your processes and functions. Which is most of the time not what you want. It is too easy for some object to get to your functions and do some modifications. Therefore, dependency injection is nice to use. (Pass the object you want to modify in the parameters, which is in this case your process-object).

To prevent others from manipulating your process-object, why not try to use some kind of singleton pattern (or even an ex-singleton pattern), so there is actually a real object to talk to? You can pass the object into the parameters of your functions if something should be modified. And then you can just have one manager that holds your process-object. Others shouldn't get to the object.

Static classes are also hard to inherit. Overriding static methods seems a bit strange. So if you are sure that the process will not be the only process, and some more specific processes will be created by you, then a static class should be avoided as well.

Static classes are commonly used for small data containers and general methods. It should not contain large data until unless required. These classes are non-extensible.

I would recommend you to have a method as static if it has only one method. In this case creating an instance of the class hardly makes sense

You can have static properties in case you want a field to act somewhat like global variable. This is a design pattern which matches Singleton pattern

I use static properties for tracking state which needs to be consumed by the whole application.

For rest everything related to my work objects is the way to go (with minor exceptions obviously)

Making extensive use of statics is like puting your application into concrete. They should be avoided except for very particular situations like utility/helper methods that are very general. A nice list was posted in a previous answer by djeeg.

The main problem I see with using static classes as you describe is that the dependencies are hardwired. If class A needs to use features from class B, it must explicitly know about it, which results in tight coupling.

While this is not always a problem, as your code grows you might find it more difficult to alter the behavior of the program to accommodate new requirements. For example, if you want to make the behavior of the program configurable, it will be difficult because that will require explicit if / switch in the code. Otherwise, you could simply make a class depend on an interface and swap implementations.

In short, you are preventing yourself from using well known design patterns that are known good solutions to solve issues you will likely encounter.

I usually try to avoid using static methods in classes. If I need to access some data globally I would at least wrap a class in a singleton. For larger projects I would recommend using an Inversion of Control container to instantiate and inject your "global" instances in a Singleton way.