Geek Answers Handbook

Is using static classes whenever I can best practice?

Let me be more precise. In my winforms project, I create classes to manage / create each part of the program. I did this to have more control over my code. For instance. I have a class that controls my DataGridView control. I called it gridManager and set all the properties, colors, etc. in it, and also I have methods for changing these parameters (for example, changeBackgroundColor (), etc.). I also have a class of this type for each panel in splitContainer. In these classes, I initialize each control that is a child of the panel and add them to this panel, setting all the properties, etc.

I wrote everything to give you a better overview for the purpose of these classes.

Now my question is: is it good to make these classes static? When are all controls and methods in a static state?

At first I had non-static ones, but when I wanted to call methods for (for example) changing colors from the Form options, I had to either pass MainForm as a parameter or do it like this:

(Application.OpenForm[0] as MainForm).gridManager.changeColor();

The static version makes this a lot easier. But that makes me wonder if this is good. I explain a lot that I hope that my not perfect English will not become even more difficult to understand. :)

+4
source share
6 answers

A global volatile state is usually bad.

Static methods / classes are good for simple free functions without side effects. Math and Enumerable are good examples.

On the other hand, you need controls inside static fields. This is a volatile state and should therefore be avoided. For example, if you want to have two instances of your form, you need two instances of your manager class. But it is static, and now you need to rewrite all the code using it.

+7
source

Like everyone, static classes have tradeoffs. The two "negative" that come to mind are

  • You cannot inherit from static classes
  • You cannot (easily) mock static classes for testing

But it seems that in your cases you will not inherit these classes, so perhaps in this case everything will be fine.

Change This assumes you are doing something like a factory control.
For example: var grid = GridManager.CreateGrid(options);

If you do something like

 var data = GridManager.GetDataFromGrid(myGrid)

I would probably redefine.

+3
source

Static classes have their place, but this is probably not one of them unless it is a quick and dirty application. If you want to have automated tests around your code, this can be almost impossible if the test code uses static classes for preference.

Better to use the singleton pattern . This way you can replace the implementation during an automatic test.

0
source

It is better to do this with the usual classes associated with this grid object. If you need another mesh object, you may need to instantiate another instance. Controllers are not the best candidate for static classes.

0
source

There can be neither good nor bad practice; its just the general picture for certain tasks.

Generally speaking, you would use static methods for functionality related to the type of the class, but not rely on any instance data to work, classic use would be something like a method of type factory that returns the initialized instance of the class to which it is attached .

 public SomeClass = SomeClass.CreateWithSomeInit(parms);
0
source

Static classes certainly have their place, but I think that using them when you can is bad advice.

The whole concept of OOP is built around instances, so most of the time you should use non-static classes. Cause? First of all, flexibility. You can have two instances that do the same thing, slightly differently, based on their internal state. You may have more implementations of the same concept, and you can easily switch them. You can use things like Inversion of Control. And so on.

0
source

More articles:


All Articles