Conventional programming wisdom seems to discourage the use of static methods in most cases. Often, I have these 'managers' e.g. UserManager, AppointmentManager e.t.c.
Invariably, one of the methods in the manager is XXX getXXX(long xxxId) e.g. User getUser(long userId).
I really don't see why this cannot be a static method. It seems very much like a factory method (a la GoF factory pattern).
It's hard to pass up the convenience of:
User user = UserManager.getUser(id);
and use
UserManager userManager = new UserManager();
User user = userManager.getUser(userId);
instead.
P.S. I believe in testing; I'm just not a 'mock-testing' fan, so I need reasons besides mocking.
The main reason to avoid static methods in object factories is the ability to keep state. Although static methods can keep their state in static fields, the approach makes it hard to save and reset the state of your factory.
In addition, it becomes impossible to program to interface of your factory, because static methods cannot be used as interface implementations. This becomes important when you need to switch implementations of your objects transparently to the rest of your application.
Finally, static methods make it harder to test your code, with or without mocking. It will be very hard for your tests to verify that certain methods of your factory are being called in a specific order.