A Case against Static Calls

I don't like static calls. Why?
You cannot mock them.
You cannot apply "Inversion of Control", specifying the class (role A) as a collaborator of the user (role B), in the user's constructor.

A static function belongs to a class, and a class is not an object (in the most enterprise- object-oriented languages). This function represents a responsability which you cannot isolate, or replace (mock). This makes the testing/maintainance harder than it should be.

In an OO world, each responsability should be materialized by an object, see the Single Responsability Principle. But a class is not an object, so you cannot treat it as a an object.

The problem is that in some languages there is no uniform access, there is a discrimination between a class and an object, therefore they must be accesed in different ways.

Another issue is that a static method does not use the instance fields/methods of the class. A static method does not belong to the object, but to the class. If the class defines the behaviour of its objects, but a static method does not belong to the objects, then it should be defined somewhere else.

That's why the singleton is an anti-pattern: the class defines the object's behaviour (responsability 1), and it's creation/life-cycle (responsability 2).
A lot of other examples we can find in Michael C. Feathers book "Working Effectively With Legacy Code", where he suggests breaking the dependencies gradually: first make a method static, then move it to another class.