When should a method be static?

Question

In addition, are there any performance advantages to static methods over instance methods?

I came across the following recently: http://www.cafeaulait.org/course/week4/22.html :

When should a method be static?

1. Neither reads from nor writes to instance fields
2. Independent of the state of the object
3. Mathematical methods that accept arguments, apply an algorithm to those arguments, and return a value
4. Factory methods that serve in lieu of constructors

I would be very interested in the feedback of the Stack Overflow community on this.

Answer 1

Make methods static when they are not part of the instance. Don't sweat the micro-optimisations.

You might find you have lots of private methods that could be static but you always call from instance methods (or each other). In that case it doesn't really matter that much. However, if you want to actually be able to test your code, and perhaps use it from elsewhere, you might want to consider making those static methods in a different, non-instantiable class.

Answer 2

Whether or not a method is static is more of a design consideration than one of efficiency. A static method belongs to a class, where a non-static method belongs to an object. If you had a Math class, you might have a few static methods to deal with addition and subtraction because these are concepts associated with Math. However, if you had a Car class, you might have a few non-static methods to change gears and steer, because those are associated with a specific car, and not the concept of cars in general.

Answer 3

Another problem with static methods is that it is quite painful to write unit tests for them - in Java, at least. You cannot mock a static method in any way. There is a post on google testing blog about this issue.

My rule of thumb is to write static methods only when they have no external dependencies (like database access, read files, emails and so on) to keep them as simple as possible.

Answer 4

@jagmal I think you've got some wires crossed somewhere - all the examples you list are clearly not static methods.

Static methods should deal entirely with abstract properties and concepts of a class - they should in no way relate to instance specific attributes (and most compilers will yell if they do).

For the car example, speed, kms driven are clearly attribute related. Gear shifting and speed calculation, when considered at the car level, are attribute dependent - but consider a carModel class that inherits from car: at this point theyy could become static methods, as the required attributes (such as wheel diameter) could be defined as constants at that level.

Answer 5

Just remember that whenever you are writing a static method, you are writing an inflexible method that cannot have it's behavior modified very easily.

You are writing procedural code, so if it makes sense to be procedural, then do it. If not, it should probably be an instance method.

This idea is taken from an article by Steve Yegge, which I think is an interesting and useful read.

Answer 6

Performance-wise, a C++ static method can be slightly faster than a non-virtual instance method, as there's no need for a 'this' pointer to get passed to the method. In turn, both will be faster than virtual methods as there's no VMT lookup needed.

But, it's likely to be right down in the noise - particularly for languages which allow unnecessary parameter passing to be optimized out.

Answer 7

Here is a related discussion as to why String.Format is static that will highlight some reasons.

Answer 8

Another thing to consider when making methods static is that anyone able to see the class is able to call a static method. Whereas when the mehtod is an instance method, only those who have access to an instance are able to call that method.