When to use static methods?

[Steve]

Hi,

I was at a JUG roundtable workshop last night where various code review
tools were being discussed.

The facilitator kept mentioning how the use of static methods made
automated code reviews more difficult and that he tried to minimize the
use of static functions.

I find static methods to be very convenient when the method doesn't need
stored ( in the class it belongs to ) values. Instead of having
to instantiate the object every time I want to use the method I just
have to type the class name and the method.

So, I would like to hear your opinion. When wouldn't I want to use
static methods aside from the obvious( the method depends on member
variable with changing values )

Steve

[markspace]

Post by Steve
I find static methods to be very convenient when the method doesn't need
stored ( in the class it belongs to ) values.

Yup. Use static methods when they are not logically part of an
instance. Collect static methods together in a single non-instantiable
class when such collections make logical sense.

Eschew automated code review tools. Seriously, wtf?

[Lew]

Post by markspace

Post by Steve
I find static methods to be very convenient when the method doesn't need
stored ( in the class it belongs to ) values.

That is a necessary but not sufficient motivation for a static method.

Post by markspace
Yup. Use static methods when they are not logically part of an

The game, Watson, is to determine by what criteria a method is deemed
"not logically part".

Post by markspace
instance. Collect static methods together in a single non-instantiable

Maybe a single class. Maybe.

Post by markspace
class when such collections make logical sense.

Oh.

Post by markspace
Eschew automated code review tools. Seriously, wtf?

Depends on what they mean by "code review tool". FindBugs and other static analysis
tools, and lints are code review tools. They are no more the code review than a power saw
is carpentry.

The game here is to use them as tools, and to use them as responsibly as a professional
would.

As for static methods, obviously they cannot depend on instance state. That is not so much
a motivation as a restriction.

But staticness, as global members are wont to do, brings other restrictions. You cannot
override a static method. You cannot declare a static method that is signature-compatible
with a supertype's instance method. You should only refer to a static member, including
methods, via the declaring type, not a subtype or instance reference. Once you declare a
method static it breaks backward binary compatibility to make it non-static, like say if
you decide you need to be able to override it. Because you can't override a static method,
you can't implement an interface's static methods in a concrete class. Concurrency is
sometimes more of an issue with static methods. It really does not make a difference to
code size whether a method is static, so there's no compelling reason ever to make a method
static except to avoid instantiation. If you have an instance of a type anyway whenever
the method is used, it's usually better to have the method tied to the instance and otherwise
harmless.

The real test of staticness, for both member variable and methods, is the "to what does it
belong?" test. If your type's architecture calls for an instance to manage whatever state and
behavior it's doing, then that instance should own all the behaviors it's doing even if they
don't directly use the instance state. If your type's architecture calls for there never to be an
instance, and you only create one to run a stateless method, then the method belongs to
the type, and should be static. If the method is designed to serve many types, not just its
owning type, and there's no other reason to have an instance own the method, it belongs
to the type. If a method serves only its own type, ever, then most likely it should not be
static, unless you are clear that its behavior belongs to the type and not any one instance.

Or in short form: Favor instance methods over static, unless compelled otherwise.

[Lew]

... Or in short form: Favor instance methods over static, unless compelled otherwise.

Addendum: The "depends on instance state" criterion is circular reasoning, if you have
mis-architected your type to have mutable static member variables on which the method
depends. Then a judgment of "depends only on global state" is a consequence of the
design error that there is global mutable state.

So that rule is more safely expressed as "depends on mutable state". This helps you
realize that mutable state should be instance state.

[Roedy Green]

Post by Steve
The facilitator kept mentioning how the use of static methods made
automated code reviews more difficult and that he tried to minimize the
use of static functions.

The main reason to use a instance method when a static method would do
it to permit it to be overridden later. I use IntelliJ whose lint
presses you not to do that. If you need overriding later then remove
the static keyword.

This may be a limitation of his lint tool.