Question

I have read the following discussions:

Should private helper methods be static if they can be static , and
Should all methods be static if their class has no member variables

It seems that people in general would accept static methods, but are a little bit skeptical about it, for the following 2 reasons:

1. They are hard to test.
2. They violate the OO principle. (They
   are functions, not methods, said a
   person.)

And the most acceptable static methods are private static ones. But then why do static methods exist at all, and in what situations they are the first priority to be adopted?

Answer 1

Static methods aren’t hard to test in and of themselves. The problem is that other code calling the static method is hard to test, because you can’t replace the static methods.

I think static methods are fine either when they’re private or when they’re “utility” methods – e.g. to do string escaping. The problem comes when you use static methods for things that you want to be able to mock out or otherwise replace within tests. Factory methods can be useful too, although dependency injection is generally a better approach – again, it partly depends on whether you want to be able to replace the functionality in tests.

As for not being “OO” – not everything you write in a generally OO language has to be “pure” OO. Sometimes the non-OO route is simply more pragmatic and leads to simpler code. Eric Lippert has a great blog post about this, which unfortunately I can’t find right now. However, there’s a comment in this post which is relevant. It talks about extension methods rather than static methods, but the principle is the same.

Extension methods are often criticized
as being “not OOP enough”. This seems
to me to be putting the cart in front
of the horse. The purpose of OOP is to
provide guidelines for the structuring
of large software projects written by
teams of people who do not need to
know the internal details of each
other’s work in order to be
productive. The purpose of C# is to be
a useful programming language that
enables our customers to be productive
on our platforms. Clearly OOP is both
useful and popular, and we’ve
therefore tried to make it easy to
program in an OOP style in C#. But the
purpose of C# is not “to be an OOP
language”. We evaluate features based
on whether they are useful to our
customers, not based on whether they
conform strictly to some abstract
academic ideal of what makes a
language object-oriented. We’ll
happily take ideas from oo,
functional, procedural, imperative,
declarative, whatever, so long as we
can make a consistent, useful product
that benefits our customers.