4

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 (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.

Anders Arpi
  • 8,277
  • 3
  • 33
  • 49
  • 1
    The first thing that jumps to my mind is why couldn't you make the "data-holding class" responsible for whatever manipulations were necessary on its data? That would avoid the need for a bunch of extra static classes, and reduce unnecessary coupling. – Cody Gray - on strike Jan 12 '11 at 10:43
  • 2
    This has already been covered extensively here, try these links for a start: [Uses for static generic classes?](http://stackoverflow.com/questions/2685046/uses-for-static-generic-classes) & [Extension Methods vs Static Utility Class](http://stackoverflow.com/questions/4646328/extension-methods-vs-static-utility-class) – slugster Jan 12 '11 at 10:52
  • 1
    The code analysis tool in VS 2008 will always recommend methods/classes should be static if they do not have or use any instance data. Is this good practice? – Polyfun Jan 12 '11 at 10:53
  • Adding the static data manipulation methods to the data-holding class? That's probably a good idea in general - however some of this data handling is for example converting the class to a HTML representation of it, which feels a bit too specific to put into the same class. But maybe I'm just looking at it the wrong way. Edit: thanks for the answers, all good ones. – Anders Arpi Jan 12 '11 at 10:53
  • It's true that a HTML writer should not be in the data holding class. Because it does not manipulate the data, so it shouldn't be there. – Marnix Jan 12 '11 at 11:04

7 Answers7

4

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
djeeg
  • 6,685
  • 3
  • 25
  • 28
2

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.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Marnix
  • 6,384
  • 4
  • 43
  • 78
1

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.

hungryMind
  • 6,931
  • 4
  • 29
  • 45
1

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)

Manish Sinha
  • 2,092
  • 2
  • 22
  • 33
1

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.

Liviu Mandras
  • 6,540
  • 2
  • 41
  • 65
1

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.

Antoine Aubry
  • 12,203
  • 10
  • 45
  • 74
1

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.

derkesthai
  • 21
  • 1