You can think of a static class as a pseudo-namespace for functions. If your functions are free of state, side-effects and dependencies, there's absolutely nothing wrong with that - for one, functions are generally easier to write tests for.
Static classes in PHP are necessary, if you want to use functions, because literal functions can't be auto-loaded.
As long as you code according to the limitations of a real namespace, those classes are effectively just namespaces that can autoload.
That said, if I have functions in a library that someone might need to override or extend in a project, I go for a stateless service class instead, and sometimes an interface for abstraction - which enables dependency injection, so that someone can replace the service with their own project-specific implementation.
For example, something like "count unique occurrences of x in y" is a good candidate for something you'd never need/want to override, while something like "calculate shipping tax" is much more likely to have a project-specific definition.
Being unable to replace functions is the only "evil" thing about static classes, assuming it abides by the other mentioned constraints.
I think that's what I'm saying, by describing it as a pseudo-namespace.
But what's your point?
Because it sounds like you're trying to build an argument. Or perhaps you're just trying to clarify the fact that it's not automatically OO just because you use the class keyword?
The interface/class example wrapping a string made it sound dangerously like you think that would actually be meaningful somehow - I'm afraid you might mislead the people you're trying explain the difference to, towards actually programming like that.
It's okay to call functions though, like how your string example calls strtoupper and several others - but it's not okay to write/call your own functions?
I understand it's "not OOP", but "should not be used"?
I think there are well founded reasons why most languages support both paradigms - there are cases for functions and cases for classes, I think, and your string example is sufficiently complex and verbose as to leave me pretty firmly convinced of that.
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.
You can think of a static class as a pseudo-namespace for functions. If your functions are free of state, side-effects and dependencies, there's absolutely nothing wrong with that - for one, functions are generally easier to write tests for.
Static classes in PHP are necessary, if you want to use functions, because literal functions can't be auto-loaded.
As long as you code according to the limitations of a real namespace, those classes are effectively just namespaces that can autoload.
That said, if I have functions in a library that someone might need to override or extend in a project, I go for a stateless service class instead, and sometimes an interface for abstraction - which enables dependency injection, so that someone can replace the service with their own project-specific implementation.
For example, something like "count unique occurrences of x in y" is a good candidate for something you'd never need/want to override, while something like "calculate shipping tax" is much more likely to have a project-specific definition.
Being unable to replace functions is the only "evil" thing about static classes, assuming it abides by the other mentioned constraints.
Yes, I agree, static classes are absolutely fine -- in procedural programming, but not in OOP.
So your argument is everything should be OOP? No one should use functions?
No, I'm just saying that static classes have nothing to do with OOP.
I think that's what I'm saying, by describing it as a pseudo-namespace.
But what's your point?
Because it sounds like you're trying to build an argument. Or perhaps you're just trying to clarify the fact that it's not automatically OO just because you use the class keyword?
The interface/class example wrapping a string made it sound dangerously like you think that would actually be meaningful somehow - I'm afraid you might mislead the people you're trying explain the difference to, towards actually programming like that.
My point is that static classes should not be used in OOP.
That example with decorated
Strings is an OOP alternative to proceduralStringUtilsclass.It's okay to call functions though, like how your string example calls
strtoupperand several others - but it's not okay to write/call your own functions?I understand it's "not OOP", but "should not be used"?
I think there are well founded reasons why most languages support both paradigms - there are cases for functions and cases for classes, I think, and your string example is sufficiently complex and verbose as to leave me pretty firmly convinced of that.