Let's say I have a class designed to be instantiated. I have several private "helper" methods inside the class that do not require access to any of the class members, and operate solely on their arguments, returning a result.
public class Example {
private Something member;
public double compute() {
double total = 0;
total += computeOne(member);
total += computeMore(member);
return total;
}
private double computeOne(Something arg) { ... }
private double computeMore(Something arg) {... }
}
Is there any particular reason to specify computeOne
and computeMore
as static methods - or any particular reason not to?
It is certainly easiest to leave them as non-static, even though they could certainly be static without causing any problems.
The advantage of private static methods is that they can be reused later if you need to reinitialize the class variable.
My personal preference would be to declare them static, as it's a clear flag that they're stateless.
From the experience I would state that such private methods tend to be quite universal and reusable.
I think the first thing to do is to ask the question whether the method may be useful outside of current class context. If so, I would do exactly what Everyone suggests and extract this method as static to some utils class where someone hopefully checks before implementing new method doing exactly the same thing.
Such general use private methods are source of big part of code duplication in project because each developer independently reinvents them just in the place she need to use it. So centralization of such methods is a way to go.
If the method is basically just a subroutine that will never foreseeably use state information, declare it static.
This allows it to be used in other static methods or in class initialization, i.e.:
As many people said, make it is as a static! Here's the thumb rule which I follow : If you think the method is just a mathematical function i.e it is stateless, doesn't involve any instance variables(=> no blue color vars [in eclipse] in the method), and the result of the method will be the same for 'n' number of calls (with the same parameters, ofcourse), then mark that method as STATIC.
And if you think that this method will be useful to other class then move it to a Util class otherwise, put the method as private in the sameclass. (minimizing the accessibility)
Yes.
By keeping them as instance methods, you allow yourself to provide a different implementation later.
It may sound silly (and actually it would be if those methods are used only by you in a 50 line program) but in larger applications, or in libraries used by someone else, you may decide to choose a better implementation, but don't want to break existing code.
So you create a subclass and return that in the new versions, and since the methods were declared as instance methods, you just let polymorphism do its job.
Additionally, you could benefit from making the constructor private and provide an static factory method for the same reason.
So, my recommendation is to keep them as instance methods, and avoid static if possible.
Take advantage of the dynamism the language provides.
See here for a somewhat related video: How to design a good API and why it matters
Although it is not directly related to the "static vs instance" method discussion, it touches on some interesting points in API design.