4 ms·

A lot of people love to try and make a case for Singletons. I have yet to see anyone make a really, truly good case for a pure software singleton. They just m

by dljsjr 13y ago

A lot of people love to try and make a case for Singletons. I have yet to see anyone make a really, truly good case for a pure software singleton. They just make it an absolute nightmare to be well informed -- as a developer -- about state in complex/concurrent/distributed systems. The only time I ever use them is when my hands are tied by some sort of hardware restriction; a JNI wrapper around some native lib that talks to proprietary hardware like a motor controller where instantiation of more than one comms object would blow out a fuse or something. And even then, I'd make the argument that the people who designed the hardware and its corresponding C API should have just made a safer interface instead of saying "Don't call `new` more than once, or else!". Seems lazy and less-than-appropriately fault tolerant.

jamesaguilar 13y ago
The only other case I can think of is when the object represents a true hardware resource (e.g. a flash queue controller). Although even that doesn't technically need to be a singleton. Another case where I've used one is when I'm caching channels to other servers created by a factory function.
RogerL 13y ago
I know what you are saying, and agree. But consider: I have state that I truly need to be global - something I read from an INI file, the command line, or internally calculated, it doesn't much matter. Is not the alternative to a singleton having that state replicated all over the place? And then you introduce model/view/ signals, have to deal perhaps with race conditions, and so on. Then, just try to grep for the existence of that state in your code. Like anything, it's a tradeoff. Let's say I have an app with 10 OpenGL windows, and I want to simultaneously control the lighting model for all at once. A singleton gives me an easy way to do that, but then the windows have to poll in some manner (which is perhaps not an issue, since they are in a render loop anyway). But I am brittle - introduce the requirement that each window handles light differently and the singleton is toast. OTOH, introducing a signal/slot or model/view architecture may be overkill for what I am doing. This might be a small corner of the code, and I just want clarity for the few times I go in to read it. I find it extraordinarily hard to understand messaging code - where did this message come from, what was the state of that object that caused it to fire the message, and so on. I think complexity goes up at least by 1 order of magnitude when you have to maintain state and time in your mind to understand a program. Perhaps not the best example; so consider command line arguments. It's read only, set once, but perhaps needed to be accessed by many different parts of my code. A singleton or 5 seems pretty darn clean to me. Again, not without it's tradeoffs, but the alternatives, to me, seem worse. You can pass, pass, pass, the data through methods and constructors until it gets to the code that needs the info - in which case you have infected a lot of code with rather superfluous (to them) knowledge about command line settings. That's brittle, and you end up touching a lot of code when you add something to the command line. You can do a signal/slot or model/view, which can be quite powerful, but you may be forced into a specific design by your sw stack (they have a model/view architecture which you are using for GUI or something). So your code is brittle by being coded to a specific API, and again, it rather obscures where this data comes from. Plus, this forces the command line reading code to know all about your specific API, how to format the signal, when to send it (command line reading is often done well before the whole stack is started up and going, so you can't send a signal yet). That's very brittle as well. Can you take that code, put it in a test harness, and trivially write tests for it? Probably not. Maybe I am missing some obvious technique. But a few things in an app are in fact global. Trying to obscure that fact, to my mind, just makes the sw more brittle and a lot harder to understand and debug. Which is not in any way an argument for making non-global things global for convenience.
- dragonwriter 13y ago
  > But a few things in an app are in fact global. Sure, but for the most part, there is no reason for the components of the app to depend on those things being global (and a significant cost in brittleness for them to do so), so, in general, they should be passed to the objects that need them, even if they are globally consistent throughout the app. Obviously, there are optimization reasons why you might need to avoid doing this in particular cases, but in general doing so up-front is going to be a premature optimization.
  - skormos 13y ago
    "...there is no reason for the components of the app to depend on those things being global..." BINGO! This is the anti-pattern part. Not that the data is globally required, but that your units are mutually dependable. This is why Interfaces and Dependency Injection are so popular now, because they facilitate the ability to make easily testable, singular units that allow for mocks / stubs etc. To illustrate, what happens if your global requirement happens to also be external? Would you want to have to test your component with a live version of your global and external resource? No, you would want the ability to test (either as a single unit, or even the whole app), without requiring the database, messaging, web service, etc, to be up.
- nightski 13y ago
  I think you really hit the core issue here with singletons. There is no problem with global state if it is truly immutable (at least after initialization). But the majority of singletons I have seen in practice (maybe my bad luck) contain mutable state. In the almost two decades I have been programming I have never come across a situation where I needed a singleton with mutable state. But hey I have not seen it all.
- skormos 13y ago
  One of the links in the original article, actually points to a StackExchange answer specifically commenting on the difference between single instance and singleton. It's a great read. http://programmers.stackexchange.com/a/40610/42446 http://programmers.stackexchange.com/a/40610/42446
727374 13y ago
Do you have any advice for avoiding singletons? Consider I have a singleton that does Geographical lookups and requires a substantial amount of time to load/process data mapping. This data never changes after the initial load. Would it be better to make the singleton private and to access it via a non-singleton instance of the class (or subclass) it lives in?
- dljsjr 13y ago
  Find a way to persist the data if it doesn't change frequently, or if you need it to be an in-memory object then pass the object around to classes that need it as others have alluded to.

by dljsjr 13y ago

jamesaguilar 13y ago

The only other case I can think of is when the object represents a true hardware resource (e.g. a flash queue controller). Although even that doesn't technically need to be a singleton. Another case where I've used one is when I'm caching channels to other servers created by a factory function.

RogerL 13y ago

I know what you are saying, and agree. But consider: I have state that I truly need to be global - something I read from an INI file, the command line, or internally calculated, it doesn't much matter. Is not the alternative to a singleton having that state replicated all over the place? And then you introduce model/view/ signals, have to deal perhaps with race conditions, and so on. Then, just try to grep for the existence of that state in your code. Like anything, it's a tradeoff. Let's say I have an app with 10 OpenGL windows, and I want to simultaneously control the lighting model for all at once. A singleton gives me an easy way to do that, but then the windows have to poll in some manner (which is perhaps not an issue, since they are in a render loop anyway). But I am brittle - introduce the requirement that each window handles light differently and the singleton is toast. OTOH, introducing a signal/slot or model/view architecture may be overkill for what I am doing. This might be a small corner of the code, and I just want clarity for the few times I go in to read it. I find it extraordinarily hard to understand messaging code - where did this message come from, what was the state of that object that caused it to fire the message, and so on. I think complexity goes up at least by 1 order of magnitude when you have to maintain state and time in your mind to understand a program. Perhaps not the best example; so consider command line arguments. It's read only, set once, but perhaps needed to be accessed by many different parts of my code. A singleton or 5 seems pretty darn clean to me. Again, not without it's tradeoffs, but the alternatives, to me, seem worse. You can pass, pass, pass, the data through methods and constructors until it gets to the code that needs the info - in which case you have infected a lot of code with rather superfluous (to them) knowledge about command line settings. That's brittle, and you end up touching a lot of code when you add something to the command line. You can do a signal/slot or model/view, which can be quite powerful, but you may be forced into a specific design by your sw stack (they have a model/view architecture which you are using for GUI or something). So your code is brittle by being coded to a specific API, and again, it rather obscures where this data comes from. Plus, this forces the command line reading code to know all about your specific API, how to format the signal, when to send it (command line reading is often done well before the whole stack is started up and going, so you can't send a signal yet). That's very brittle as well. Can you take that code, put it in a test harness, and trivially write tests for it? Probably not. Maybe I am missing some obvious technique. But a few things in an app are in fact global. Trying to obscure that fact, to my mind, just makes the sw more brittle and a lot harder to understand and debug. Which is not in any way an argument for making non-global things global for convenience.

dragonwriter 13y ago
> But a few things in an app are in fact global. Sure, but for the most part, there is no reason for the components of the app to depend on those things being global (and a significant cost in brittleness for them to do so), so, in general, they should be passed to the objects that need them, even if they are globally consistent throughout the app. Obviously, there are optimization reasons why you might need to avoid doing this in particular cases, but in general doing so up-front is going to be a premature optimization.
- skormos 13y ago
  "...there is no reason for the components of the app to depend on those things being global..." BINGO! This is the anti-pattern part. Not that the data is globally required, but that your units are mutually dependable. This is why Interfaces and Dependency Injection are so popular now, because they facilitate the ability to make easily testable, singular units that allow for mocks / stubs etc. To illustrate, what happens if your global requirement happens to also be external? Would you want to have to test your component with a live version of your global and external resource? No, you would want the ability to test (either as a single unit, or even the whole app), without requiring the database, messaging, web service, etc, to be up.
nightski 13y ago
I think you really hit the core issue here with singletons. There is no problem with global state if it is truly immutable (at least after initialization). But the majority of singletons I have seen in practice (maybe my bad luck) contain mutable state. In the almost two decades I have been programming I have never come across a situation where I needed a singleton with mutable state. But hey I have not seen it all.
skormos 13y ago
One of the links in the original article, actually points to a StackExchange answer specifically commenting on the difference between single instance and singleton. It's a great read. http://programmers.stackexchange.com/a/40610/42446 http://programmers.stackexchange.com/a/40610/42446

727374 13y ago

Do you have any advice for avoiding singletons? Consider I have a singleton that does Geographical lookups and requires a substantial amount of time to load/process data mapping. This data never changes after the initial load. Would it be better to make the singleton private and to access it via a non-singleton instance of the class (or subclass) it lives in?

dljsjr 13y ago
Find a way to persist the data if it doesn't change frequently, or if you need it to be an in-memory object then pass the object around to classes that need it as others have alluded to.