The problem with static methods is mockability and more generally substitutability. Although there are mocking frameworks which will allow you to mock static methods, there is broader support for mocking a non-static method, and it’s simple to do yourself by subclassing.

Say I’m testing class A which interacts with class B. If it calls only non-static members of B, then I can inject a replacement for B which behaves the way I need, for instance for testing. But if it calls a static member of B, it’s hard (depending on your mocking framework, sometimes impossible) to mock. So I have to use a real B – or the real B class – in my test of A; now I have a more complicated test, and one which is testing more than the unit (A) I’m interested in. It’s more fragile and harder to reason about than if I can just mock out the method.

I think that’s the best rationale for avoiding static methods.

I feel like static method’s encourage behavior like this. In this case we have a global class with a static function. We are hiding the fact that Foo depends on StaticWorker.DoWork().

Static Method

public class Foo
{
    public void Bar()
    {
        StaticWorker.DoWork();
    }
}

On the other hand, instance-level methods encourage passing the dependent object. Which is better than reaching into a global.

Instance Method

public class Foo
{
    Worker Worker;

    public Foo(Worker worker)
    {
        this.Worker = worker;
    }

    public void Bar()
    {
        this.Worker.DoWork();
    }
}

Now of course you could pass in a function, but I still like the abstraction I get with objects.

Another huge benefit of instance-level methods is that the class can implement an interface which you cannot do for a static method.

This is similar to the singleton argument. Singleton’s themselves don’t cause damage if used properly, but it makes it easier for people to call the singleton all over their code without passing it, once again creating invisible dependencies and global state.

There are exceptions to the rule. Sometimes you have a small, lightweight method. It will never change, and is not a dependency for anything else, I might make it static. You have to use your best judgement on a case by case basis, but I would say favor instances, especially if you have any doubts.

I feel like there are several benefits to using instance methods and all I have to do is instantiate an object. A small price to pay for the rewards.

Declaring a pure functions as static is correct in my opinion. It would be awkward to require creating an instance of a stateless object just to call a function.

There are cases however where you need them to be in an object instance. For example when you pass that function to another method, as you do with a Comparator in a sort method. More generally, when you need to substitute your function, or a set of functions by another one, you’ll need an instance.

The bad reputation of static methods comes from when they are used as a substitute for the Singleton pattern. But in this case, there is some state stored in static variables.