Onyedika Paul's post rings a bell.
I once had someone saying I was using too many static methods. That I should "follow best practices" and create a constructor and instantiate it so I could use dependency injection, design patterns, singleton, etc.
But none of it required dependency injection, singleton, neither required any of the 3 pillars of object orientation:
- encapsulation
- inheritance
- polymorphism
It was just a very simple flow: get parameters, callout to authenticate, callout to get data, then save data.
There was no reason to add bloated code other than to "look professional" in someone's mind who used to see code always following a particular pattern.
The assumption that static methods are automatically an anti-pattern is itself a thought anti-pattern. Static is a tool and, like any tool, it solves certain classes of problems cleanly and creates friction in others.
If no state needs to be persisted across calls, if no variation in behavior is expected, if no substitution of collaborator objects is needed, if the logic is deterministic and side-effect-free and if the code forms a simple procedural pipeline -> then static is a good tool for it.
On the other hand, if we need to swap implementations at runtime, or need to mock collaborators in unit tests, or need stateful lifecycle management, or the class is expected to evolve into more complex coordination logic, static methods can become a liability.
Otherwise, if none of those are true, there is no structural advantage to always add constructors or injected services.
Some people either misapply Uncle Bob’s guidance or have a reflexive adherence to Dependency Injection-based architectures. DI frameworks normalize certain shapes of code, so some people internalize a rule: static = bad. But that rule is false outside of contexts where DI provides real benefits.
