Take the 2-minute tour ×

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.

share|improve this question
What are the "known problems" with static methods? –  Robert Harvey Aug 31 '11 at 16:02
@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. –  Robert Harvey Aug 31 '11 at 16:09
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. –  Tamás Szelei Aug 31 '11 at 16:14
@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. –  Robert Harvey Aug 31 '11 at 16:21
@TamásSzelei How are they prone to modify global state? They can't even find global state unless you pass it into a parameter. –  CodesInChaos Mar 23 '12 at 19:25
show 3 more comments

3 Answers

up vote 11 down vote accepted

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.

share|improve this answer
add comment

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?

share|improve this answer
Thank you. I explained my concerns in the comments under the question. –  Tamás Szelei Aug 31 '11 at 18:20
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 Aug 31 '11 at 21:39
add comment

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.

share|improve this answer
The class containing the static method is already occupying memory anyway. Your fear of the static keyword seems unfounded. –  Robert Harvey Aug 31 '11 at 16:08
add comment

Your Answer


