Take the 2-minute tour ×

This question already has an answer here:

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.

share|improve this question
Thanks. Was unable to find it. –  Andrey Vityuk Mar 26 '09 at 20:26
add comment

marked as duplicate by Bill the Lizard Jun 18 at 21:05


7 Answers

up vote 10 down vote accepted

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)

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
This could happen when I need to apply specific checks for input parameters in some public method. Like some sort of small helper method. –  Andrey Vityuk Mar 26 '09 at 12:43
...or when you are dealing with the static fields, obviously =8-) –  Yuval Mar 26 '09 at 12:47
@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 :) –  Eric Petroelje Mar 26 '09 at 12:54
I guess that the common answer is "I am using a language that doesn't allow free functions" –  D.Shawley Mar 26 '09 at 12:59
If you make them package-private, you can unit test them too. –  Tom Hawtin - tackline Mar 26 '09 at 12:59
show 1 more comment

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.

share|improve this answer
add comment

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

share|improve this answer
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. –  Andrey Vityuk Mar 26 '09 at 12:45
Urgh. Don't group methods randomly. –  Tom Hawtin - tackline Mar 26 '09 at 12:58
add comment

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.

share|improve this answer
add comment
