Should all methods be static if their class has no member variables

Question

I\'ve just had an argument with someone I work with and it\'s really bugging me. If you have a class which just has methods like calculateRisk or/and calc

Answer 1

It is a tough call. Remember what Josh Bloch says about APIs:

APIs, like diamonds, are forever. You have one chance to get it right so give it your best.

(This may not be a public API, but if you have colleagues that are going to use this code, it effectively is an API.) If you declare those methods static, you constrain their future evolution, and incorporating state in the class will be difficult or impossible. You are going to have to live with those static method signatures. If you decide to make them non-static down the road because you need state, you are going to break the client code. I would say, when in doubt, don't make them static. That said, there is a place for static utility classes that contain a bunch of functions (e.g. calculate the area of a circle.) Your class may fall into that category.

Answer 2

Imo, they should be static. I see no reason why they shouldn't be, since instance objects would have no state, and calling the methods without instantiating would require less code and thus improved readability.

Actually, i would probably make sure the class won't be instantiated by making it abstract.

Answer 3

I believe that stateless methods should generally be static.

• It's clear in the code that no object is involved
• It avoids a meaningless constructor invocation

I can see breaking this rule for a strategy-pattern implementation, as a number of people have noted here.

Answer 4

Statics smell

In most cases, a static method is an example of behavior divorced from data. It indicates something is not encapsulated. e.g. if you see validate methods for phone number, email etc in util classes, ask why they aren't these fields don't have their own classes. Even library classes can be extended to accommodate custom behavior. Finally in special cases like java.lang.String (which is final) you could use a custom myproject.String (with additional behavior) that delegates to java.lang.String

Objects are the way to access behavior in OO languages. It is not useful to worry about the cost of object instantiation and use statics instead. For most business software, this is a 'penny wise pound foolish' approach to performance.

Sometimes, you use functors (methods that don't use object state) for expressing intent. Doesn't mean they should be made static. IDE warnings that suggest "method can be made static" should not be taken seriously.

Answer 5

I clearly would say no.

It's much harder to change out in the future if you call static methods instead of instance ones. With instance methods it's easy to inject your service, e.g. in Java with an IoC/DI container like Guice or Spring.

Answer 6

It depends what your goal is:

If your goal is to write as few lines of code as possible, the static approach would be the best.

If your goal is testability, we've discovered that static methods are a bugger to mock out. We, sadly, end up writing an interface, and a class for some of these just to be able to mock them out easily.