4

Let me be more precise. In my winforms project im creating classes to manage/create every part of the program. I did it to have more control over my code. E.g. I have a class that manages my DataGridView control. I named it gridManager and in it i set all properties, colors and so on and also i have methods to change those settings (e.g. changeBackgroundColor() etc). I also have this type of class for each Panel in splitContainer. In those classes i initialize every Control that is a child of panel i add them to that panel set all properties and so on.

I wrote it all to give you better view at the purpose of those classes.

Now my question is: is it good practice to make this classes static? With all controls and methods inside being static?

At first i had them non-static but when i wanted to call methods for (e.g.) changing color from options Form i had to either pass MainForm as a parameter or do it like this:

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

Static version of it makes it a lot easier. But it makes me wonder if its a good thing to do. Uh a lot of explaining i hope my not perfect English wont make it even more difficult to understand. :)

Improve this question

6 Answers 6

Reset to default
8

Global mutable state is usually a bad idea.

Static methods/classes are good for simple sideeffect free functions. Math and Enumerable are good examples.

You on the other hand want controls inside static fields. These are mutable state and thus should be avoided. For example if you tomorrow want to have two instances of your form, you need two instances of your manager class. But it's static and you now need to rewrite all the code using it.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

3

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

  1. You can't inherit from static classes
  2. You can't (easily) mock static classes for testing

But it sounds like in your cases you wouldn't be doing any inheritance of these classes anyway, so perhaps in this case it would be okay.

Edit This is assuming you're doing something like a control factory.
For example: var grid = GridManager.CreateGrid(options);

If you're doing something like

var data = GridManager.GetDataFromGrid(myGrid)

I'd probably reconsider.

Improve this answer

Comments

0

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

It might be better to use the singleton pattern. This way you can replace the implementation during the automated test.

Improve this answer

1 Comment

I'd even avoid the standard singleton pattern where possible. IMO it is preferable to register it as singleton in your DI container. That way you don't bake the assumption that something is a singleton into the consuming code.
0

You better do it with normal classes that is linked to that grid object. If you need another grid object you may need to instantiate another instance. Controllers are not the best candidate for static classes.

Improve this answer

Comments

0

Its neither good nor bad practice, its just a common pattern for certain tasks.

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

public SomeClass = SomeClass.CreateWithSomeInit(parms);
Improve this answer

Comments

0

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

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

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.