Brazol
Brazol

Reputation: 455

Is using static classes whenever i can good practice?

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. :)

Upvotes: 4

Views: 2814

Answers (6)

svick
svick

Reputation: 245076

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.

Upvotes: 0

CodesInChaos
CodesInChaos

Reputation: 108880

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.

Upvotes: 8

Tim Jarvis
Tim Jarvis

Reputation: 18825

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);

Upvotes: 0

Cem Kalyoncu
Cem Kalyoncu

Reputation: 14603

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.

Upvotes: 0

agent-j
agent-j

Reputation: 27953

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.

Upvotes: 0

taylonr
taylonr

Reputation: 10790

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.

Upvotes: 3

Related Questions