I think the article is quite correct. But there is a critical unstated assumption: that static classes operate on a shared mutable state. The correct use of static methods are as deterministic functions. For example String.Join(",", strings) is probably deterministic in a given language, making it easily testable and understandable.
There's no such assumption. Every issue I've listed holds true without it.
Eh, not really. I mean I get it... statics are incompatible with OOP or "objects all the way down" philosophy. Right on. But they have valid uses which remain testable and maintainable, albeit not following the OOP philosophy.
Anyway, not meant to argue your main point. I think you are right. Just that there are nuances to every tool. Best wishes!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the article is quite correct. But there is a critical unstated assumption: that static classes operate on a shared mutable state. The correct use of static methods are as deterministic functions. For example
String.Join(",", strings)
is probably deterministic in a given language, making it easily testable and understandable.There's no such assumption. Every issue I've listed holds true without it. And concerning your example, here is how I would write it:
It looks way more declarative, human-readable, composable and reusable.
Eh, not really. I mean I get it... statics are incompatible with OOP or "objects all the way down" philosophy. Right on. But they have valid uses which remain testable and maintainable, albeit not following the OOP philosophy.
Anyway, not meant to argue your main point. I think you are right. Just that there are nuances to every tool. Best wishes!