When to go to static classes?

Question

Whenever I code a solution to something, I tend to either use a lot of static classes, or nothing at all. For example, in a recent project, I had to send a class with some string / bool / datetime data through several hoops, and the only element that was not static was this data storage class. Everything else (3 pretty cool classes with different processing tasks) were static.

I think that what I am asking here is some information on when (and why) I should avoid using static classes for these "processes X, output Y". Is it possible to always use them while they work, or am I shooting myself in the foot regarding scalability, plugin support, etc.

Hope this is a OK question to ask here. I am not asking for arguments as to whether static classes are "best" - just enter when I should avoid using them.

Answer 1

Still two questions remain a little the same. My main concern for static classes is inheritance and accessibility.

By using a static class (public in the worst case) everyone can access your processes and functions. Which in most cases is not what you want. For some objects, it’s too easy to get to your functions and make some changes. Thus, addiction injection is good to use. (Pass the object you want to change in the parameters, in this case your process-object ).

So that others can not manipulate your process-object , why not try to use some kind of singleton template (or even an ex-singleton template), so that there really is a real object for communication? You can pass the object to the parameters of your functions if something needs to be changed. And then you can only have one manager that holds your process-object . Others should not fall into the facility.

Static classes are also hard to inherit. Overriding static methods seems a bit odd. Therefore, 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.

Answer 2

Most of the code I write is:

• Uses dependency injection / IoC
• And you need to be mock / checked

So, I just use objects for almost everyone.

I still use statics for things like:

• Extension Methods
• Constants
• Helper methods (pre extension methods)
• operator methods

Answer 3

Static classes are commonly used for small data containers and common methods. It should not contain big data until it is needed. These classes are not extensible.

Answer 4

I would recommend that you use the method as static if it has only one method. In this case, instantiating the class hardly makes sense

You can have static properties if you want the field to act as a global variable . This is a design pattern that matches the Singleton pattern

I use static properties for tracking status, which should be consumed by the entire application.

For recreation, everything connected with my work objects is the way (with minor exceptions).

Answer 5

The widespread use of statics is how to apply your application to a particular one. They should be avoided, except in special situations, such as utilities / helper methods, which are very common. A good list was posted in djeeg's previous answer.

Answer 6

The main problem that I see when using static classes in the description is that dependencies are tightly bound. If class A must use the functions of class B, it must explicitly be aware of this, which leads to tight coupling.

Although this is not always a problem, as your code grows, it may be more difficult for you to change the behavior of the program to meet new requirements. For example, if you want to customize the behavior of the program, it will be difficult, because this will require an explicit if / switch in the code. Otherwise, you could just make the class dependent on the interface and implementation of swap.

In short, you're stopping yourself from using well-known design patterns that are well-known good solutions to solve problems you are likely to encounter.

Answer 7

I usually try to avoid using static methods in classes. If I need to access some data around the world, I would at least wrap the class in a singleton. For larger projects, I would recommend using the Inversion of Control container to instantiate global instances using the Singleton method.