When to make a method static?

Question

I'd like to know how people decide whether to define a method as static. I'm aware that a method can only be defined as static if it doesn't require access to instance fields. So let's say we have a method that does not access instance fields, do you always define such a method as static, or only if you need to call it statically (without a reference to an instance).

Perhaps another way of asking the same question is whether you use static or non-static as the default?

Answer 1

If what the method does depend solely on its arguments, you can make it static. If the method does not instantiate any other of your user defined classes, you can make it static. The default, though, is to have it as non-static.

Answer 2

Use static methods when you are performing operations that do not operate on instances of the class.

A perfect example would be a sqrt method of a Math class.

Answer 3

You are wrong about static methods not being able to access instance fields. For example:

class A {
   public:
      static void setx( A & a, int n ) {
         a.x = n;    // access instance fields
      }
   private:
      int x;
};

...

A a;
A::setx( a, 42 );

Answer 4

Non static by default, static when I need the functionality to be available from at least two different classes, and I don't want to waste a constructor.

ps. Archimedes rules!

Answer 5

I use static methods whenever I can. Advantages:

• When calling a static method from inside an instance method, you can be sure that there are no side-effects on the state of the current object.
• From inside a static method, you can be sure you don't accidentally modify any state of the object instance.
• You can use a static method from outside the class without constructing an instance. If it was possible to make the method static, it clearly doesn't need an instance, so there's no need to require one.
• Static methods may be slightly more efficient because no "this" pointer needs to be passed.

Answer 6

It depends. In languages where non-member functions are possible I'd say that most of the time, if the method could be made static, it should be made a non-member function instead, non-friend if possible. You can tell I have a mostly C++ background.

In "pure" OO languages where non-member functions are not possible it would depend on whether the method is only "incidentally" static (i.e. it just happens not to need access to instance members), or is truly logically static - it is a method of the whole class instead of for a particular instance.

Answer 7

Kevin Bourrillion wrote an insightful answer on this topic some time ago (admittedly from a Java perspective, but I think it's applicable to other languages too).

He argues that you should basically only use static methods for pure functions.

A "pure function" is any method which does not modify any state and whose result depends on nothing but the parameters provided to it. So, for example, any function that performs I/O (directly or indirectly) is not a pure function, but Math.sqrt(), of course, is.

I tend to agree. (Although in my own code, traditionally, I've probably used way too many static helper methods all over the place... :-P And this surely has made code that uses those methods harder to test.)

Answer 8

(C#) By default, I use static methods in static classes and non-static methods in non-static classes.

As I elaborate a class, I find myself naturally converging on making it entirely static or entirely non-static. Practially speaking, if I start wanting to define static members within a non-static class, I often find that it will eventually make the most sense to break those out into a separate static class -- either a utility class like Math or a global application class (like .NET's ConfigurationManager).

From an object-oriented perspective, a method is doing something to/with an object. So if you're using an instantiated object, it makes the most sense to me to think of that object's methods as non-static. Technically, you technically can make a non-static class have static members if they don't require access to an instance. But ostensibly, at least, a class's methods would still be doing something to/with that class, so I would still make them non-static. All things being equal, that is.