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
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.