I created a private validation method for a certain validation that happens multiple times in my class (I can't store the validated data for various reasons). Now, ReSharper suggests that the function could be made static. I'm a little reluctant to do so due known problems with static methods. It would be a private static method. My question is, can private static methods cause similar coupling and testing problems like public static methods? Is it a bad practice? I would guess not, but I'm not sure if there is a pitfall here.

  • 10
    What are the "known problems" with static methods? Commented Aug 31, 2011 at 16:02
  • 3
    @Ed: Right. Properly-written static methods should not touch external API's or state anyway. Manipulating internal state encapsulated within a class seems perfectly OK to me, and the method would not need to be unit-tested, since unit testing tests the external behavior of the class. Commented Aug 31, 2011 at 16:09
  • 1
    Static methods are prone to modifying global state and they also kill inheritance (any time you want to extend functionality, you'll need to modify the calling code because you can't override the method in a derived class). Your are tied to that one implementation. Static methods can't be mocked which makes them very difficult to unit-test. They hide dependency. I'm sure there is more. Not to just blindly avoid them, I'm asking to make an informed decision. Commented Aug 31, 2011 at 16:14
  • 2
    @Tamás Static methods only modify global state if you write them that way, which I never do. Generally speaking, I only use static methods in utility classes, methods which take one or more objects and return an object without side effects. These kinds of methods have none of the problems you describe. Commented Aug 31, 2011 at 16:21
  • 1
    @TamásSzelei How are they prone to modify global state? They can't even find global state unless you pass it into a parameter. Commented Mar 23, 2012 at 19:25

3 Answers 3


I would think: "Do I need to test this?"

If your method is private anyway, meaning you don't want to unit test the logic in the method itself, then as far as testability and maintainability are concerned your class is a black box either way, the inner workings of your class are its business and its alone. Refactoring will not be affected either, which is also something to consider.

So, in my opinion: No, making a "private" method "private static" will have no long term ramifications whatsoever.


Private static methods are the easiest thing possible, from my point of view.

DataIn -> Method -> DataOut

There are no dependencies on external objects, no side effects. Why do you consider them bad?

  • Thank you. I explained my concerns in the comments under the question. Commented Aug 31, 2011 at 18:20
  • 2
    What you describe is only correct for static methods not depending on static member variables - that is what can make a difference between a "good" and a "bad" static method.
    – Doc Brown
    Commented Aug 31, 2011 at 21:39

Testing classes that use public static methods can be hard, as it's not (particularly) easy to stub / fake / mock out the static methods. Instance methods, on the other hand, can be mocked easily, especially if they're virtual or satisfy an interface.

However, I can't see any reason to not use private static methods. Indeed, there's a slight performance benefit, as you don't need an instance of the class to occupy memory.

On the other hand anything static is a bit of a code smell. Is this actually a "helper class"? Could it be that the method could more usefully reside on one of the classes passed as a parameter? The answer to those questions is often "it's fine as a static" but it's worth remembering.

  • The class containing the static method is already occupying memory anyway. Your fear of the static keyword seems unfounded. Commented Aug 31, 2011 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.