When to use static classes and methods?

Question

I have a general question...when should i be using static classes or static methods?.. I know the idea that static methods can be called without instantiating...and static classes should only be used for static methods?...but are there any performance concerns also with it...and when should they be preferred over instance methods and classes?..If someone could just briefly mention when i should opt for using them and when i should avoid them?

Answer 1

I think the following two links offer a clear answer for what you're looking for. Take a look at them:

For static classes:

When to Use Static Classes in C#

For static methods:

When is it appropriate to use static methods? ( Jon Skeet [the Guru] answered this one :o) )

Answer 2

There is a previous entry here is seems: http://stackoverflow.com/questions/241339/when-to-use-static-classes-in-c

I would think static classes are for holding functions or data that you want to call without having to create an object for it. If I recall, instantiating an object places it in memory. And by implication, a non object static class does not go into memory? Been a while since I took my theory classes ;( Sorry.

Answer 3

I think a general rule of thumb could be that utility functions should be static. A typical example would be how in any oop language a Math class would contain static methods like sqrt(), since there is really no need to have something like a separate Math object.

As for static classes you should think of classes keeping a form of state, typically like session information, which is needed irrespective of the exact path travelled through your application, and of which you typically need exactly one. (think of your browser, probably always keeping exactly 1 cookie-jar like class)

Static variables are the less evil twin of global variables (they keep their value, but with their scope limited to a function), which are typically useful to either keep some form of state (e.g. caching of data) or to enumerate things that should be unique but whose numbering is not very important outside the scope of your function or application (say, numbering debugging or profiling cries from your own debug("..") or profile() functions)

Basically, only use any of them when you are very sure that doing things the "right" OOP-like way would lead to the creation of a monster.

Answer 4

As I understand it that's when there's no sense to create an object of a class to invoke an action or that class is common within the application. For example, in C#, Console class is sealed (so you can't create an object and inherit it, and there's really no sense to do it). But professionals will explain you better, however.

Answer 5

One thing to keep in mind is the testing implications of static methods. A static method "seals" a lot of seams. Seams are where you can change behavior without changing your production code; examples are subclassing, or linking to a testing library. Since static methods are resolved at compile time and aren't dynamically bound you can't throw in a testing object and change the way a static method behaves. Testing that class is going to be a drag.

For things like mathematical functions you can be pretty sure a static method will be ok, but you almost certainly wouldn't want a static method that connects to a database. Think about how you'd test code that uses a static method you're thinking of making.

Here's a good link from the google testing blog:Static Methods are Death to Testability

Answer 6

It's VB Envy. They are jealous of our Modules.