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.
asked Aug 31, 2011 at 15:49
-
10What are the "known problems" with static methods?– Robert HarveyCommented 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.– Robert HarveyCommented Aug 31, 2011 at 16:09
-
1Static 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 SzeleiCommented 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.– Robert HarveyCommented 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.– CodesInChaosCommented Mar 23, 2012 at 19:25
|
Show 3 more comments
3 Answers
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
-
2What 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. 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
statickeyword seems unfounded. Commented Aug 31, 2011 at 16:08