Summary: singletons = global variables + static methods.
Details:
If you need some "utility function" whose output depends exclusively on its arguments, you will be better of with an static method. However, this is a no fly for O-O-purists.
The option is to create a (possibly stateless) singleton class and put your non static method there. You will have the overhead of acquire the reference to the method in run time instead of compile time (and the few bytes needed to store the class and the ONE object reference).
On the other hand, singletons can be used to hold global state and the methods to legally change that global state. For this reason, they can be easily abused in order to bypass separation of concern rules and dress them in OOP-speak.
Because they have a state, I would suppose. My memory is actually foggy on why Singletons are bad. I guess they make it hard to make the app distributable, and they are generally error prone? Like how to make sure there really is only one of them.
Static fields are also state. Singletons have a bad rep in C++-land and similar because they have initialization problems - static initialization is a PITA with C-oriented linkers.
A lot of the problem here is branding. Schemes that are isomorphic with one another, and called singletons in one language and modules in another, are respectively reviled and lauded, sometimes by the same people.
It's my position that the question "why are singletons worse than static methods" is ill-formed and implies a dichotomy where there need not be one. Static methods are already instance methods on an implied singleton, whose state consists of static state; except this singleton doesn't have an identity and isn't a value that you can pass around, and so isn't composable, isn't first-class.
Sure, in that sense it is the same. I was thinking about methods without side effects. Then it wouldn't matter if they exist in several instances, I suppose.
Comments
Why are singletons worse than static methods?
Summary: singletons = global variables + static methods.
Details:
If you need some "utility function" whose output depends exclusively on its arguments, you will be better of with an static method. However, this is a no fly for O-O-purists.
The option is to create a (possibly stateless) singleton class and put your non static method there. You will have the overhead of acquire the reference to the method in run time instead of compile time (and the few bytes needed to store the class and the ONE object reference).
On the other hand, singletons can be used to hold global state and the methods to legally change that global state. For this reason, they can be easily abused in order to bypass separation of concern rules and dress them in OOP-speak.
Because they have a state, I would suppose. My memory is actually foggy on why Singletons are bad. I guess they make it hard to make the app distributable, and they are generally error prone? Like how to make sure there really is only one of them.
Static fields are also state. Singletons have a bad rep in C++-land and similar because they have initialization problems - static initialization is a PITA with C-oriented linkers.
A lot of the problem here is branding. Schemes that are isomorphic with one another, and called singletons in one language and modules in another, are respectively reviled and lauded, sometimes by the same people.
The question was about static methods, though.
It's my position that the question "why are singletons worse than static methods" is ill-formed and implies a dichotomy where there need not be one. Static methods are already instance methods on an implied singleton, whose state consists of static state; except this singleton doesn't have an identity and isn't a value that you can pass around, and so isn't composable, isn't first-class.
Sure, in that sense it is the same. I was thinking about methods without side effects. Then it wouldn't matter if they exist in several instances, I suppose.