The Old Joel on Software Forum: Part 3 (of 5)

Java Static Methods

I haven't weighed in on this myself (I tend to agree with sfitzjava's comments) but the Java developer's amongst you might like to add to the comments re: the use of static methods in Java in the discussion on the java.net site - http://today.java.net/pub/a/today/2003/12/30/staticsSQ1.html

This would also have applicability in the .NET world and particularly for VB/C developers transitioning to .NET languages (comments seem to suggest that developers coming from a procedural background are [more] fond of static methods).

Walter Rumsby
Thursday, January 8, 2004

static methods creates necessary classes in the background anyway, if I recall.. so I am not sure about the savings... the .Net Framework regular expression classes has static method versions of find and replace...

Li-fan Chen
Thursday, January 8, 2004

If a method can go either way, I wouldn't make it static.

It's slightly disorienting when a non-static method calls a static method in the same class. Someone reading the code would pause to consider why the method is static.

Also, at some point in the future you might want to change the method to access non-static members of the class. It's easier to make it non-static from the beginning for greater flexibility later on.

Julian
Thursday, January 8, 2004

Static methods can't be polymorphic. So even for a method that doesn't require any instance fields, if there is a chance of needing to override it in subclasses, it shouldn't be made static.

Generally I only use static methods for:

1. Factory methods
2. Utility classes that have nothing but static methods
3. Classes that function as high-level scripts intended to be called from the command line - they have nothing but a main() and some static methods helping the main one.

T. Norman
Thursday, January 8, 2004

In practice, I think it's usually a non-issue. But as a mental exercise, my answer is yes, always declare a method to be static if you can.

Crimson
Friday, January 9, 2004

What T Norman said.

Li-fan Chen
Friday, January 9, 2004

In C# (not sure about other languages in .NET), there is a disconnect when calling static methods. For instance, this isn't valid:

Foobar x = new Foobar();
x.StaticMethod(...);

Would yield the following compiler error:

error CS0176: Static member 'Foobar.StaticMethod()' cannot be accessed with an instance reference; qualify it with a type name instead

Routinely making things static as an academic exercise is not a good idea. Static methods are not polymorphic, can't be used implement interface methods, and represent a change in signature when changing whether they are static or not.

Adding in the mechanical changes required for C# code really just seals the deal, as far as I'm concerned.

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, January 9, 2004

By the way, for those who say "do it always", what's your justification? Please tell me it's not "saving a few byte of stack space".

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, January 9, 2004

I remember reading an article in Java Developer's Journal that said that calling static methods is faster (less overhead) than non static methods (makes sense to me).

Generally speaking, my personal rule of thumb is, do not make the method static unless you have a *good reason* for doing so.

Avrom Finkelstein
Friday, January 9, 2004

I suspect some of those who like statics-as-much-as-possible also like functional programming. Too bad this is a masochistic desire in the Java context. Unless you use some preprocessor or other jvm language.

Tayssir John Gabbour
Friday, January 9, 2004

If the method is private, ie it's an implementation detail, make it static if it doesn't access any members. It improves encapsulation and abstraction, and doesn't effect client code anyway. If this were C++, I would probably even put it in an anonymous namespace - not have it be part of the class at all.
If the method is public, you can't just change it at will, because of the different syntaxes for accessing the methods (as others have noted). Go with the modifier/syntax that conceptually makes the most sense (and you will probably choose static).

Brian
Friday, January 9, 2004

--
If the method is private, ie it's an implementation detail, make it static if it doesn't access any members. It improves encapsulation and abstraction, and doesn't effect client code anyway.
--

How does a private static method improve encapsulation?? I don't see how it hurts encapsulation, but neither do I see how it improves either abstraction or encapsulation?

I generally declare all of my methods to be non-static by default. My reasons are similar to those of T. Norman.

I once worked on a program where almost all methods were declared as final static methods (for "performance" reasons). The program didn't really need to run fast and the savings gained were minimal at best. The cost for this tiny performance boost was a great deal of pain whenever parts of the program need to be modified in a polymorphic way.

The problem with declaring a static method is that you don't have access to any of the member variables. Sometimes that is ok. Other times as your design evolves you may want access to those variables. If you've sprinkled a dozen uses of your static method throughout your code you're going to have to do some cleanup first.

NathanJ
Friday, January 9, 2004