What's the benefit of doing it that way? The only one you mentioned is self-documentation, but that seems like a weak argument against these kind of singletons. It sounds like you're giving up the convenience of singletons solely for the sake of not having singletons, which seems pointless in itself.
I read that as not having singletons for the sake of self documenting code dependencies. In a way, a singleton is a "magic" dependency that can reach into the middle of your code without a trace. By always passing it in, you're making it explicit. This is the same as the pure functional discipline of having all values passed in, never coded into a function.
I'm giving up singletons because hidden dependencies are a source of bugs. Let me make it more concrete:
Suppose classes A, B, and C use singleton class S, and S has state. Via the hidden dependency on S, it's possible for A, B, and C to affect each other without explicitly calling each other's methods.
As a programmer, you can take those hidden interactions into account and still have a relatively bug-free program. But it's one more thing you have to hold in your head. When you return to the project six months later, you have to read through the internal code of A, B, and C to see these interactions; the public APIs don't reveal them. You spend more time figuring out how the objects interact, and there's a greater chance you'll fail to notice an interaction.
In the general case, I agree. But for a very few things, singletons make fine sense. Usually in small programs where you can draw the entire object graph on a single piece of paper, and where all the features it will have are known up front.
Certainly! Tiny programs are the exception to most best practices. (Not security best practices, but I digress.) I write a lot of little programs, and they're certainly not all works of art. Sometimes you need to bang out a tiny program quickly, and it's never going to become a maintenance burden. In which case you can use any pattern or anti-pattern you like.
That sounds like a very black/white way to say it. I don't agree that using a singleton in small programs is an anti-pattern. The world is much more gray than that.
I said you can use anti-patterns in small programs, not that singleton is an example of an anti-pattern. I don't believe singleton is so terrible as to be an anti-pattern, even for big programs. I just think it has some downsides that are really worth considering before you use it.
This article echoes the same idea (instead of big singleton, view controllers should accept the data they require in their initializer (constructor)) and gives some reasons why to do it this way:
This is mostly an argument against making AppDelegate into a God object, which I totally agree with. It's not saying singletons themselves are inherently bad. It does generalize saying that they usually make it difficult to evolve an app's internals, but I disagree with that. As long as they're chosen when appropriate, and used properly, there's no problem.
Bingo. If you want to test class Foo in isolation, it is essential to know that it depends on Bar. Furthermore, when taking testing seriously, you might want to test Foo's behaviour in combination with differently configured instances of Bar - which is only possible if Bar is not a singleton.
