Using private static methods

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.

From stackoverflow

• 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?

  Andrey Vityuk : This could happen when I need to apply specific checks for input parameters in some public method. Like some sort of small helper method.

  Yuval : ...or when you are dealing with the static fields, obviously =8-)

  Eric Petroelje : @Andrey - that makes perfect sense. Like I said, it's just the first question I would ask myself if I found myself doing the same thing. Often those "helper" methods can be useful for other things and are better refactored into another class. But then, sometimes they aren't too :)

  D.Shawley : I guess that the common answer is "I am using a language that doesn't allow free functions"

  Tom Hawtin - tackline : If you make them package-private, you can unit test them too.

  Andrey Vityuk : @Eric - yes, they often tends to be extracted to some utility class :)

• 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.

• 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.

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

  Andrey Vityuk : And what do you used to do with methods which are too specific for sharing? For the some general functionality I also extract methods to utility classes.

  Tom Hawtin - tackline : Urgh. Don't group methods randomly.

• 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.

• 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.

• 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