Using private static methods [duplicate]

Question

This question already has an answer here:

• Should private helper methods be static if they can be static 21 answers

What do you think about using private static methods?

Personally, I prefer using a static private method to non-static as long as it does not require access to any instance fields.

But I heard that this practice violates OOP principles.

Edit: I am wondering from style prospective of view, not performance.

Answer 1

A private static method by itself does not violate OOP per se, but when you have a lot of these methods on a class that don't need (and cannot*) access instance fields, you are not programming in an OO way, because "object" implies state + operations on that state defined together. Why are you putting these methods on that class, if they don't need any state?

(*) = In principle, due to the class level visibility in Java, a static method on a class has access to instance fields of an object of that class, for example:

class Test
{
  int field = 123;

  private static void accessInstance(Test test)
  {
    System.out.println(test.field);
  }
}

You need to pass in the reference to an instance (this pointer) yourself of course, but then you are essentially mimicking instance methods. Just mentioning this for completeness.

Answer 2

As mentioned above, private static methods are often useful for organizing re-used logic and reducing/eliminating repeated code. I'm surprised that I haven't noticed any mention of performance in this discussion. From Renaud Waldura's 'The Final Word on Final':

(Note, private static methods are implicitly final)

"Since a final method is only implemented in the declaring class, there is no need to dynamically dispatch a call to a final method, and static invocation can be used instead. The compiler can emit a direct call to the method, bypassing entirely the usual virtual method invocation procedure. Because of this, final methods are also candidates for inlining by a Just-In-Time compiler or a similar optimization tool. (Remember, private/static methods are already final, therefore always considered for this optimization.)"

Check out the whole paper: http://renaud.waldura.com/doc/java/final-keyword.shtml

Answer 3

private or public doesn't make a difference - static methods are OK, but if you find you're using them all the time (and of course instance methods that don't access any instance fields are basically static methods for this purpose), then you probably need to rethink the design. It's not always possible, but most of the time methods should reside with the data they operate on - that's the basic idea of OOP.

Answer 4

I don't necessarily see any real problem with what you are doing, but my first question would be if the method doesn't require access to any instance fields, then what is it doing in that class in the first place?

Answer 5

It's a matter of taste, but I make methods that don't react to a state within the object static. This way I don't have to rewrite code if a static function needs similar functionality. A sorting function would be a good example of such a case.

Answer 6

I tend not to use private static methods. I do use public static methods and group them into Util classes to promote reuse.

Answer 7

Private static methods can for example operate on private static members of their class. This can be utilized to encapsulate and unify certain class specific operations.

The major drawback of using static methods is in my opinion the fact that one throws away the possibility to override. Since classes in Java are not like, let's say, classes in Smalltalk, you can not override static methods.

Since your question relates to private static methods, overriding is out of option anyway.

I tend to use static methods only in case of utility classes (like java.lang.Math) or patterns like the Singleton pattern. All of these require a higher visibility than private, because they represent services provided by their class to others.

Final thought: If you have one or more private static methods, think about extracting them to a dedicated utility class and making them public. Even better, make them instance methods and use the Singleton pattern.