6 ms·

I have concluded that singletons should not be used ever for anything. Because practically always there appears a situation when a singleton has to be used as a

I have concluded that singletons should not be used ever for anything. Because practically always there appears a situation when a singleton has to be used as a doubleton or multipleton, and doing such refactoring is a mess. I am not even talking about such things as automated testing, multithreading, self-referencing, the order of initialization, etc.

smrtinsert 12y ago
Agree 1000%. Haven't used once since 2002 since I started using di containers.
- cpitman 12y ago
  Exactly, the "Singleton" pattern should only be used when having two instances of one object will be catastrophic. In all other situations where you only think you want one of a class, dependency injection handles that. A good DI container will even keep track of your pseudo-singleton for you. Then unit testing becomes feasible again, without having to hack around that Class X is using the "ConnectionManager" to connect to the database behind your back.
  - dkersten 12y ago
    I always laughed when people said "yeah, but, why would you ever want two ConnectionManagers? What if you create more than one accidentally! Make it a singleton and that can't happen!" My reply was along the lines of "when was the last time you accidentally wrote two for loops when you wanted only one? If you don't want more than one ConnectionManagers then don't create more than one" In my opinion its very rare that you need an object that is both globally accessible and you must not have more than one.
swalsh 12y ago
I think that's kind of like the goto keyword rule. For 99% of the situations, its true. You can avoid it. 1% of the time though, its a really clean way to accomplish a specific type of task.
jschwartzi 12y ago
A new feature I was working on a few months ago at my job was held up for two weeks while a developer who wrote some underlying code removed the singleton he wrote and replaced it with a not-singleton. This was so that we could have different versions of a simple C struct datastore for different stored configurations.
logfromblammo 12y ago
Singleton vs. Anti-Singleton is a holy war. Some (perhaps most) people who use singletons use them inappropriately. That does not imply that there is no situation for which using one would be appropriate. The pattern is not to blame, but the close coupling, global state, multiple responsibility, and dependency hiding that are enabled by it. They're perfectly fine as resource managers or for immutable references. Also, premature optimization is an anti-pattern. The advantage of singleton is that it is super easy to set up, and get to working code, then refactor it out immediately afterward. If removing it does not improve the code, it must belong there, right? That said, it's pretty easy to improve the code by removing it.
- teacup50 12y ago
  Removing a singleton is incredibly costly due to the "close coupling, global state, multiple responsibility, and dependency hiding that are enabled by it". If I were to compile a top 10 list of terrible refactoring projects I've worked on, ALL of them would be on code that had stalled out due to a "singleton" global variable code-complexity ceiling. Anti-singleton is a holy war because the people who produce such shockingly crap singleton-riddled code are externalizing enormous and soul-crushing costs onto both customers and future maintainers.
  - logfromblammo 12y ago
    I guess we know which side you're on, then. I'd caution against inverting the conditional probability of writes singletons given unskilled programmer into probability of unskilled programmer given writes singletons. It's a fallacious operation. You can't eliminate bad code by eliminating singletons. You can only do it by turning unskilled programmers into skilled programmers. "Don't use singletons" is fine advice for a novice, but it would be better to teach the principles that underlie that advice and use Socratic questioning to make them realize that MOST uses of singleton violate one or more of those principles.
    - perdunov 12y ago
      You're right that writing singletons needs expertise because there are a number of (possibly unsolvable) gotchas that you need to know about to even start using singletons. Take the self-referencing problem: let's say we have a logger singleton (pretty simple, what could possibly go wrong?) And let's say that the logger singleton invokes particular code during its initialization, such as the file I/O code that is also our own and that uses... guess what? a logger! Thus, when the logger class initializes, it will either try to log using an uninitialized object or invoke the initialization recursively depending on whether the singleton is lazy or not. A beginner is normally not aware of this problem when they are writing their singleton class. Another problem is the initialization order: what is initialized first - the logger singleton or the I/O singleton? Turns out, we just have to use lazy initialization. Then the multithreading comes on the scene. So you have to make a thread safe lazy singleton. But that implies additional cost on every call for the singleton. I don't know... Singletons are a mess.

smrtinsert 12y ago

Agree 1000%. Haven't used once since 2002 since I started using di containers.

cpitman 12y ago
Exactly, the "Singleton" pattern should only be used when having two instances of one object will be catastrophic. In all other situations where you only think you want one of a class, dependency injection handles that. A good DI container will even keep track of your pseudo-singleton for you. Then unit testing becomes feasible again, without having to hack around that Class X is using the "ConnectionManager" to connect to the database behind your back.
- dkersten 12y ago
  I always laughed when people said "yeah, but, why would you ever want two ConnectionManagers? What if you create more than one accidentally! Make it a singleton and that can't happen!" My reply was along the lines of "when was the last time you accidentally wrote two for loops when you wanted only one? If you don't want more than one ConnectionManagers then don't create more than one" In my opinion its very rare that you need an object that is both globally accessible and you must not have more than one.

swalsh 12y ago

I think that's kind of like the goto keyword rule. For 99% of the situations, its true. You can avoid it. 1% of the time though, its a really clean way to accomplish a specific type of task.

jschwartzi 12y ago

A new feature I was working on a few months ago at my job was held up for two weeks while a developer who wrote some underlying code removed the singleton he wrote and replaced it with a not-singleton. This was so that we could have different versions of a simple C struct datastore for different stored configurations.

logfromblammo 12y ago

Singleton vs. Anti-Singleton is a holy war. Some (perhaps most) people who use singletons use them inappropriately. That does not imply that there is no situation for which using one would be appropriate. The pattern is not to blame, but the close coupling, global state, multiple responsibility, and dependency hiding that are enabled by it. They're perfectly fine as resource managers or for immutable references. Also, premature optimization is an anti-pattern. The advantage of singleton is that it is super easy to set up, and get to working code, then refactor it out immediately afterward. If removing it does not improve the code, it must belong there, right? That said, it's pretty easy to improve the code by removing it.

teacup50 12y ago
Removing a singleton is incredibly costly due to the "close coupling, global state, multiple responsibility, and dependency hiding that are enabled by it". If I were to compile a top 10 list of terrible refactoring projects I've worked on, ALL of them would be on code that had stalled out due to a "singleton" global variable code-complexity ceiling. Anti-singleton is a holy war because the people who produce such shockingly crap singleton-riddled code are externalizing enormous and soul-crushing costs onto both customers and future maintainers.
- logfromblammo 12y ago
  I guess we know which side you're on, then. I'd caution against inverting the conditional probability of writes singletons given unskilled programmer into probability of unskilled programmer given writes singletons. It's a fallacious operation. You can't eliminate bad code by eliminating singletons. You can only do it by turning unskilled programmers into skilled programmers. "Don't use singletons" is fine advice for a novice, but it would be better to teach the principles that underlie that advice and use Socratic questioning to make them realize that MOST uses of singleton violate one or more of those principles.
  - perdunov 12y ago
    You're right that writing singletons needs expertise because there are a number of (possibly unsolvable) gotchas that you need to know about to even start using singletons. Take the self-referencing problem: let's say we have a logger singleton (pretty simple, what could possibly go wrong?) And let's say that the logger singleton invokes particular code during its initialization, such as the file I/O code that is also our own and that uses... guess what? a logger! Thus, when the logger class initializes, it will either try to log using an uninitialized object or invoke the initialization recursively depending on whether the singleton is lazy or not. A beginner is normally not aware of this problem when they are writing their singleton class. Another problem is the initialization order: what is initialized first - the logger singleton or the I/O singleton? Turns out, we just have to use lazy initialization. Then the multithreading comes on the scene. So you have to make a thread safe lazy singleton. But that implies additional cost on every call for the singleton. I don't know... Singletons are a mess.