53

Possible Duplicate:
What is so bad about Singletons?

It's understandable that many design patterns can in some cases be abused, and like mom always said: "Too much of a good thing isn't always good!"

I'm noticing that these days, I'm using Singletons a lot, and I'm worried that I might be abusing the design pattern myself, and running deeper and deeper into a bad-practice kind of habit.

We're developing a Flex application that has a quite a large hierarchical data structure kept in memory while the user works on it. The user can load, save, change and refresh the data on demand.

This data is centralized by means of a Singleton class, which aggregates a couple of ArrayCollections, Arrays, value objects and some other native member variables exposed via getters and setters.

To get a reference to our data from anywhere in the application, we do the whole Model.getInstance() method type of thing, that I'm sure everyone is familiar with. This ensures that we always get our hands on the same copy of data, since when we designed, we said that only once instance is allowed to exist during the application lifetime.

From this central data repository, it's then easy for us to for example, dispatch property changed events, and can have multiple UI components that reference the central data, update their displays to reflect the data changes that have occurred.

So far, this approach has been effective and proven very practical to our circumstances.

I'm finding however, that I'm a little overeager when creating new classes. Questions like should a class be a Singleton, or should it rather be managed some other way, like maybe using a factory for example, tend to sometimes become a bit difficult, with a bit of uncertainty.

Where do I draw the line with singletons? Is there a good guideline for deciding when to use Singletons and when to stay away from them.

Also, can anyone recommend a good book on design patterns?

Community
  • 1
  • 1
josef.van.niekerk
  • 11,301
  • 17
  • 86
  • 144
  • 1
    There are a number of similar questions to this, but I'm not really sure if any of them could be considered "exact duplicates"... – Zifre Jun 19 '09 at 22:28
  • 3 people recommending the same book in under 5 minutes must be a record. And a hint :-) – Stu Jun 19 '09 at 22:32
  • 1
    the problem, on any case, is the excess (ab-use) – BlackTigerX Jun 19 '09 at 22:37
  • my $0.02 is that in Flex, most solid design principles go out the window because of the stupid hoops you're forced to jump through. I point you to the HierarchicalCollectionView interface for a prime example... – rmeador Jun 19 '09 at 22:48

12 Answers12

111

Yes, singletons are bad. They are bad because all they do for you is combine two properties, each of which is bad about 95% of the time. (Which would mean that on average, singletons are bad 99.75% of the time ;))

A singleton, as defined by the GoF, is a data structure which:

  1. Grants global access to an object, and
  2. Enforces that only one instance of the object can ever exist.

The first is generally considered a bad thing. We don't like globals. The second is a bit more subtle, but generally, there are virtually no cases where this is a reasonable restriction to enforce.

Sometimes, it only makes sense to have one instance of an object. In which case you choose to create only one. You don't need a singleton to enforce it.

And usually, even when it "makes sense" to have only one instance, it turns out not to make sense after all. Sooner or later, you're going to need more than one logger. Or more than one database. Or you're going to have to recreate resources for each of your unit tests, which means we have to be able to create them at will. It is prematurely removing flexibility from our code, before we understand the consequences.

Singletons hide dependencies and increase coupling (every class can potentially depend on a singleton, which means the class can not be reused in other projects unless we also reuse all our singletons), and because these dependencies are not immediately visible (as function/constructor parameters), we don't notice them, and typically don't think about it when we create them. It's so easy to just pull in a singleton, it acts almost as a local variable and all, so we tend to use them a lot once they're there. And that makes them almost impossible to remove again. You end up, perhaps not with spaghetti code, but with spaghetti dependency graphs. And sooner or later, your runaway dependencies will mean that singletons start depending on each others, and then you get circular dependencies when one is attempted initialized.

They make it extremely hard to unit-test. (How do you test a function that calls functions on a singleton object? We don't want the actual singleton code to be exercised, but how do we prevent that?

Yes, singletons are bad.

Sometimes, you really want a global. Then use a global, not a singleton.

Sometimes, very very very rarely, you may have a situation where creating multiple instance of a class is an error, where it can not be done without causing errors. (About the only case I can think of, and even that is contrived, is if you're representing some hardware device. You only have one GPU, so if you're going to map it to an object in your code, it would make sense that only one instance can exist). But if you find yourself in such a situation (and again, for emphasis, a situation where multiple instances cause serious errors, not just a situation where "I can't think of any use cases for more than one instance"), then enforce that constraint, but do it without also making the object globally visible.

Each of these two properties can be useful, in rare cases. But I can't think of a single case where the combination of them would be a good thing.

Unfortunately, a lot of people have got the idea that "Singletons are OOP-compliant globals." No, they're not. They still suffer the same problems as globals, in addition to introducing some other, completely unrelated ones. There is absolutely no reason to prefer a singleton over a plain old global.

jalf
  • 229,000
  • 47
  • 328
  • 537
  • 15
    There are tons of times when enforcing a singleton is a critical idea. Think of a database connection pool. You wouldn't want two separate pools, as you would possibly open connections when there may be some already available. – Kekoa Jun 19 '09 at 23:15
  • 45
    Why wouldn't I want two separate pools in my unit tests? Why wouldn't I want two separate pools for separate databases? Why wouldn't I want two separate pools if I have two separate tasks that shouldn't be allowed to starve out each other? One task might hog all the connections in its own pool, so I want to reserve some for the other. But even if you *do* absolutely positively want only one pool, why do you need a singleton to enforce it? Do you often *accidentally* create new connection pools? Of course not. If you only need one, just *create* one. – jalf Jun 19 '09 at 23:24
  • 3
    +1 Couldn't have said it better. Exactly how I feel and educate my fellow colleagues. Many points also apply to the monostate pattern and (ab)use of global static methods. – gix Jun 20 '09 at 02:58
  • 4
    Issue 1 is the real killer, because it is so hard to fix once you have sprinkled it all over your code. – starblue Jun 20 '09 at 05:41
  • 1
    I wish I could favorite answers (again). – Jeff Sternal Mar 11 '10 at 14:39
  • 2
    I guess I should point to what I wrote on my blog some months after this answer: http://jalf.dk/blog/2010/03/singletons-solving-problems-you-didnt-know-you-never-had-since-1995/ – jalf Apr 12 '11 at 16:42
  • I nearly completely agree with you and you've argued the point well. But I'm still cautious about saying there are no exceptions. For example: if you have a database you probably have tables that are reference lists, eg types of employee (Director, Admin, User etc). That table is arguably a single global variable. And you simply can't create another copy of that table (think primary and foreign keys). In that case how would you argue that representing that table with a singleton that provides a list of immutable user type objects does any harm? – Justin Doyle Dec 20 '11 at 22:24
  • @JustinDoyle: Why can't multiple copies of that table exist? I might have multiple databases with the same structure. Or I might just want to create a copy of the table, which is clearly possible, as long as the database constraints are respected. But moreover, it is not clear to me that (1) the table should be mapped to a single distinct type, and (2) that type, if it exists, should have a *globally accessible* instance. As another justification for having multiple instances, consider that I'll probably want to write tests, and I don't want them to operate directly on the production db – jalf Dec 20 '11 at 22:40
  • I'd want a private copy of the table, or perhaps a separate implementation which just uses in-memory data, which can be instantiated at will, so that each test can get a clean instance to work with. But I can't *prove* that there are no exceptions. But my philosophy is that until I find an exception, I'll work from the assumption that none exist. – jalf Dec 20 '11 at 22:41
  • jalf, what I'm talking about is the equivalent of a global constant, not a global variable. Since the objects are immutable there's no need to get a 'clean' instance. Something akin to Colors.x maybe. Yes you can make another list of Colors that's identical to Colors if you want but it's not 'Colors'. You can make a copy of the table but it's not the table. Colors is also globally available, is that a problem? 1) I'm talking specifically about reference lists. 2) sometimes particular lists are global to the domain of the application. Do you need separate lists of all the states? – Justin Doyle Dec 20 '11 at 23:12
  • On testing, of course you wouldn't want it pulling from the production database, but it would be easy to change the connection so the data that the singleton is pulling during your tests is from a test database or a mock object. See the question above. – Justin Doyle Dec 20 '11 at 23:56
  • @Justin: You don't typically have a singleton `Black`, do you? I can create as many instances of a black color as I like. So why would you have a singleton database table? The entire point in a singleton is that it *cannot* be copied, and it *cannot* be instantiated. And it is globally accessible to *every* part of your code. I don't see the need for those three constraints on the color black, and likewise, I don't see why you'd want them on a database table either. I certainly don't want my database to be visible to *every* part of my application. – jalf Dec 21 '11 at 08:34
  • @jalf, perhaps I'm not explaining myself well enough. I'm not suggesting making a _Black_ singleton. I'm suggesting making _Colors_ a singleton. As in a canonical list of colors that will always be the same! I don't want to set text to Colors.Black and end up with red text. Colors is accessible anywhere in your code, hell, anywhere in _anyone's_ code if you include the reference. System.Environment.Newline is also accessible to _every_ part of your code. It doesn't matter though because it's not a variable. – Justin Doyle Dec 21 '11 at 23:25
  • @JustinDoyle: I don't see how any of that would benefit from being made a singleton. If iI want the color Black, I would typically call a function (or a property, in C#) which *generates* an instance of the color black. I don't need that function to be part of a singleton, and there is no reason why it should be. I don't see the relevance. You **could** put all sorts of things into a singleton, sure. But why would you? – jalf Jan 08 '12 at 11:49
  • well if you want to have multiple database connection, you can put a method inside a singleton that access the database connection in multiton pattern way – Netorica Jul 26 '12 at 09:50
  • 1
    Of course you *can*. You can also make every single variable in your program a global, and replace every single function call by a `goto`. Or you could put on a blindfold while coding. But why would you want to? – jalf Jul 26 '12 at 10:12
  • @JustinDoyle you're saying singleton, but the pattern doesn't pertain to what you want. You're simply talking about a class with public static constants. There's no need for the singleton pattern in that case, you just make a class with the constants you need. So you can reference black as Colors.black, but you would not need to do Colors.instance().black, it's unnecessary. – Chaseph Dec 04 '13 at 06:01
  • 1
    @jaif your answer is pretty good, but this line irks me: "Sometimes, it only makes sense to have one instance of an object. In which case you choose to create only one. You don't need a singleton to enforce it." Whenever people use this argument, I tend to think they've never developed with more than 2 people on a project before. You create abstractions and defenses because these things happen when people are working on different parts of a system and don't realize the interactions with parts they aren't working on. – Chaseph Dec 04 '13 at 06:04
  • 1
    @user1748902 what can I say? I *have* worked with more than two people on a project. And I frequently run into a lot of pain because someone in the past decided that something should be a singleton because *they* only saw a need for one instance. I have never ever been in a situation where a coworker, past or present, caused problems by creating a second instance of an object that only needed to be instantiated once – jalf Dec 04 '13 at 09:28
  • 1
    @user1748902 there are two sides to it: even if you can only see a need for one instance, you should still write the class to *work* if a second instance is created. Then it is not the end of the world if a coworker decides to create a separate instance. – jalf Dec 04 '13 at 09:31
  • 4
    @user The other side is that your coworkers common sense is probably just as good as yours. You wrote the object intending for one instance to exist. He created a second instance. Who are you to say that *he is wrong*? He encountered a situation where it made sense to create a second instance, that you hadn't anticipated. If it had been a singleton then your coworker would have been unable to do what he thought made sense. My argument is that "should a second instance exist?" is a decision that can only reasonably be made when the class is *used*, not when it was originally designed. – jalf Dec 04 '13 at 09:32
  • Gotta love the old "but we are not a team!" argument. – R. Martinho Fernandes Dec 04 '13 at 09:38
  • @user1748902 If you need one instance now but possible more than one instance in the future, may I suggest the [n-ton Pattern](http://stackoverflow.com/questions/14662673/)? It gives you the flexibility to change your mind later and create exactly as many instances as you need! – fredoverflow Dec 04 '13 at 09:42
  • 1
    I voted you down because you statement "there are virtually no cases where this is a reasonable restriction to enforce" is patently false. – gshauger Jul 06 '14 at 02:22
  • 1
    Despite the subjective nature of your argument you would simply disagree with any example that I or anyone else put forward. You do realize this is all subjective right? It's obvious from your posts that you're too close minded to understand that for many developers it's the solution that makes perfect sense. – gshauger Jul 10 '14 at 03:19
  • @gshauger No, I do not realize that it is "all subjective". I listed real factual and objective reasons to avoid singletons. You on the other hand, refuse to supply *any* reasons, subjective or objective, why I'm wrong. I'm sorry, but if your best argument is "nyah nyah, you're close minded", then I think we're done here. I *thought* when you said my statement was "patently false", that you had something better to support it with than "oh, it's all subjective, but you're dumb". But I guess not? – jalf Jul 10 '14 at 21:45
  • I think you've misunderstood the rule `Grants global access to an object` (also I think the rule has poor choice of words) As it is connected to the 2. rule, it means that you can call it from everywhere and you still get the 1 thing, it does **NOT** mean you can globally access it *literally* - that is something totally different - and **that really is wrong**. Is singleton used badly many times? Yes. Is it a good design for *what is supposted to do*? Yes, but only for that. – jave.web Sep 05 '19 at 17:50
42

The key thing to remember is that design patterns are just a tool to help you understand the abstract concepts. Once you have that understanding, restricting yourself specifically to a "recipe" from a book is pointless and hurts your ability to write the code most appropriate for your purpose.

That said, reading books like GoF will present you with more ways to think about problems so that when the time comes to implement something on your own, you'll have a wider set of perspectives to approach the problem from.

In your case, if using singleton makes sense in every case, then go right ahead. If it "sort of" fits and you have to implement it in some clunky way, then you need to come up with a new solution. Forcing a pattern that isn't perfect is somewhat like hammering a square peg in a round hole.

Given that you say "this approach has been effective and proven very practical to our circumstances," I think you're doing fine.

Here are some good books:

Gang of Four Book - the classic book for design patterns

Head First Design Patterns - I've heard this recommended by a few people as an alternative

mandaleeka
  • 6,427
  • 1
  • 25
  • 34
  • Thank you all so much!!! I'll definitely get a copy of at all these books, and work my way through them. I think I've heard about the "Gang of Four Book" somewhere. – josef.van.niekerk Jun 19 '09 at 22:58
  • 10
    Most of the rest of the GoF book is fine, but on the subject of singletons, I seriously think they must have been smoking something illegal. Either that, or it was a concession to old procedural programmers (who really want their globals), in order to win them over to OOP ("Hey look, you can make globals in OOP too! We just call them singletons") – jalf Jun 19 '09 at 23:02
  • 2
    Yeah, I'll second what jalf says, beware of using singletons as just a oop version of global variables. – Simon P Stevens Jun 19 '09 at 23:49
  • Singleton is always a sign of non-reenterable code, in most cases it is also a sign of untestable code. Their existence can only be justified with faster time to market when maintenance aspect is not of a concern. Even logger, classically considered a valid singleton usecase in C++ may cause the application to crash when a class is logging from the destructor and singleton logger is already gone. – bobah Feb 04 '14 at 12:02
14

Software developers seem to be pretty evenly split into two camps, depending on whether they favor an idealistic coding style or a pragmatic one:

  • Idealistic: Never use the singleton pattern.
  • Pragmatic: Avoid the singleton pattern.

Personally, I favor the pragmatic approach. Sometimes it makes sense to break the rules, but only if you really understand what you are doing and are willing to accept the associated risks. If you can answer "yes" to the questions below regarding your specific use case, the singleton pattern can yield some practical benefits.

  • Is the singleton external to your app? Databases, queuing services, and ESBs are all perfectly valid macro examples of the singleton pattern.
  • KISS: Is you entire app limited to 2-3 internal singletons?
  • DRY: Are those singletons inherently global and would therefore result in having to plumb references into almost every object in your app? (e.g., a logger or component mediator)?
  • Do your singletons depend only on each other, and/or the operating environment?
  • Have you ensured proper start-up and shut-down sequences for each singleton, including memory management considerations? For example, a "Grand Central"-style thread pool may need to have instance Run() and Shutdown() methods in main() so that tasks are guaranteed to run only when the objects they operate on are in a valid state.
kgriffs
  • 3,860
  • 3
  • 33
  • 42
  • 2
    Nice way to make your singleton-addiction more socially acceptable. "I avoid them, I only use them where it makes sense". No you don't. From your own description, you use them all over the place, any time the alternative would require just a small amount of work. The distinction isn't between "idealistic" and "pragmatic", but between those who *actually* try to avoid singletons (I don't *need* a singleton for my database connection, for example), and those who *say* they "avoid" them, when really they just mean "I use them when I think it's the right thing to do" – jalf Jan 19 '13 at 11:40
  • 1
    @jalf The point is to keep an open mind, remain educated on what singletons are good at and what they are bad at, and to then pick the right tool for the task at hand. My philosophy is that any developer can use any design pattern so long as they can sufficiently defend it. Like how in the C# world, it's considered smelly to use things like `unsafe` and `goto` in the vast majority of cases, yet both of them are semi-frequently used in the source code of .NET itself. If you know the pros and cons of all options and still decide to use singletons, then that's perfectly fine. – Abion47 Nov 05 '18 at 18:51
  • 1
    Nothing sets off red flags in my mind of a developer's capabilities and mindset quite like hearing that something should _never_ be done, period, end of discussion. To me, that just says the developer is locked into a certain way of thinking, and it makes me concerned that they aren't going to be flexible enough to keep up with the competitive and ever-evolving world of software development. I've heard too many stories of people who ruled their development teams with an iron fist using antiquated technologies and conventions while quashing any discussion of change without even consideration. – Abion47 Nov 05 '18 at 18:55
9

Singletons don't kill programs, programmers kill programs.

Like any programming construct, when used appropriately, you will not shoot yourself in the foot.

The books recommended are fine, but they don't always give enough background that comes with experience on when you might make the choice to use Singleton.

That experience only comes when you've found Singleton is a bad choice when you need to have multiple instances, and all of a sudden, you've got a lot of trouble injecting the object references everywhere.

Sometimes it's better to go ahead and have the object references in place, but the fact that you are using Singleton at all does help to identify the scope of the problem you would face if you had to refactor it to a different design. Which I believe is a very good thing: i.e. just having a class at all (even if poorly designed) gives some ability to see the effects of a change to the class.

Cade Roux
  • 83,561
  • 38
  • 170
  • 259
4

We have started a project where we are basically facing the same question, that is, how to access the model, and especially its root element. The project is not a Flex app, but a play! web app, but that doesn't matter really.

Having a single object unique in the system is fine, the problem is how to access it. So the debate about singleton is related to the notion of dependency injection (DI), and how to obtain objects.

The main arguments for DI are the following:

  • testability and mocking
  • decoupling object instantiation from usage (which can lead to lifecycle management)
  • separation of concerns

Possible approaches for DI are (see the classic article from Fowler):

  • to pass object around in method parameters
  • service locator
  • DI framework

Under this perspective, the singleton pattern is just a kind of service locator, e.g. Model.getInstance().

But to provide maximum flexibility in face of future changes, the reference to the unique object should be passed around as much as possible, and obtained with Model.getInstance() only when necessary. This will also yield cleaner code.

Masih
  • 1,495
  • 4
  • 16
  • 35
ewernli
  • 36,434
  • 4
  • 82
  • 119
3

In my opinion the use of Singletons directly signals a design flaw. The reason is simply that they allow one to bypass the normal object creation and destruction mechanisms built into C++. If an object needs a reference to another object, it should either pass in a reference to it upon construction or create a new instance of it internally. But when you use a singleton you're explicitly obfuscating the creation and teardown cycle. A related problem is that it is extremely difficult to control the lifetime of a singleton. As a result, many packages which include generic singleton implementations also include clunky object lifetime managers and the like. Sometimes I wonder if these don't exist simply to manage the singletons.

Basically, if you need to use an object in many places, it should be created explicitly at the highest common point in the stack and then passed down via reference to everybody who uses it. Sometimes people use Singletons because they have problems passing multiple args to new threads, but don't fall for this, explicitly define your thread args and pass them to the new thread in the same manner. You'll find that your program flows much cleaner and there are no nasty surprises due to static initialization dependencies or erroneous teardown.

Andy B
  • 31
  • 1
2

Singletons are certainly not bad. They have their uses, some of them very good. Singletons do tend to be overused by inexperienced developers as it's often the first design patten they learn about, and it's fairly simple, so they chuck it around all over the place without thinking about the implications.

Every time you want to use a singleton, try to consider why you are doing it, and what are the benefits and negatives of using this pattern.

Singletons do effectively create a global accessible set of 'stuff' (either data or methods) and I think most people would agree that using too many global variables is not a great idea. The whole point of classes and object orientation is to group things into discrete areas rather than just chucking everything into one massive global space.

One of the 'patterns' I find I tend to prefer over singletons is to pass needed objects down from the top. I create them once during my apps initialization phase, and a pass them down through all the objects that need access to them. It mimics the 'single-creation' part of a singleton pattern, but without the 'global' part.

The whole point of a singleton is that it's for objects where only 1 should ever exist. You mention a data control set of classes. Perhaps consider that actually, there are cases where an app might want to create 2 sets of data control classes, so perhaps enforcing a singleton on this isn't quite right. Instead, if you created these data classes on app init, and passed them down, you would be only creating 1 set as that is what you current app requires, but you leave open the possibility that at some point, if you need a second set you can easily create them. Also, should data control classes really be accessibly globaly from anywhere in the app. I think not, instead they should probably be only accessible from a lower level data access layer.

Some people have recommended the GOF book. I would say, yes that is a great book, but first try and find a book on general architecture first, read about 2/3/n-tier design, encapsulation, abstraction, and these kind of principles first. This will give you a more solid base with which to understand the appropriate usage of the patterns the GOF talk about.

[Edit: The other time that a singleton variant can be useful is when you want a single access point to something, but the implementation detail might actually be more than one thing. The caller doesn't need to know, that under the covers their request for the singleton object is actually resolved against several available objects and one is returned. I'm thinking of something like a thread pool here, where the use goes, hey, just get me a thread, I need 1, but I don't care which one]

Simon P Stevens
  • 26,147
  • 3
  • 73
  • 103
  • 1
    The thread pool is a great example of singletons backfiring. The .NET thread pool works like that, and it is a pain. It means I can't create a thread pool for tasks in my application. I have to share it with the .NET class library, any third-party libs I might be using, and god knows what else. I have absolutely no way to tell how likely it is to even *have* a free thread. A sane design would be to make a thread pool class that *anyone* can instantiate if they want their *own* thread pool, and then expose a single global thread pool we can use when we don't care how many other users exist. – jalf Jun 19 '09 at 23:35
  • 1
    @jaif: I feel like you've missed the point of he threadpool. It's there for very quick simple dirty tasks that you want done off the main thread, if you care about getting a free thread or if you want more control you can use the Thread class, or the BackgroundWorker. If you want your own personal user managed pool of threads you can look at implementing a producer-consumer pattern (see half way down this page: http://www.albahari.com/threading/part4.aspx). The whole point of the thread pool is that it's meant to balance async work across the whole system, not just your app. – Simon P Stevens Jun 19 '09 at 23:47
  • 3
    Why should *I* have to implement this pattern myself, when .NET already tried to do it for me? The point is that if they had not hard-coded it as a singleton, it would have done the job across the whole system that it does not, *in addition* to being useful in smaller scopes within my own app. It is a perfect example of singletons removing flexibility for no reason. I'm not missing the point of the thread pool, I'm saying that with a tiny modification, it would have been far more generally useful. – jalf Jun 20 '09 at 13:34
  • 1
    If you created multiple thread pools how would they balance themselves.I think what you want is something different.I can't see how multiple thread pools would work.The thread pool *is* a system wide pool of threads,that is there to balance work across apps,and there *is* just one of them,so a singleton is appropriate way of accessing it.Yes, perhaps MS should implement a producer-consumer thread queue as well,but they can't provide for everything.Anyway, lets not argue too much about it,I'm sure MS have their reasons for doing it the way they did,we have to live with that for good or for bad. – Simon P Stevens Jun 20 '09 at 14:18
2

I know this is an old thread but no one seemed to mention the actual pattern that fits what the OP was attempting to do. What I believe he is describing a need for is called the Mediator Pattern. SourceMaking is a fantastic site for learning / referencing this kind of information. Definitely my go to place for introducing people to software patterns. Also, it's generally a good idea to not buy into the notion that any design pattern is necessarily inherently good or evil. They all have their use, it's only learning when and where to use them that is the trick. People who state never to use Singletons, to me, don't understand their usefulness.

jpeffer
  • 73
  • 1
  • 2
  • 6
0

No, they're not necessarily bad.

As for a book, you need to start with the classics.

Stu
  • 14,881
  • 4
  • 37
  • 73
0

Singletons are not "that bad". If you have a lot of related Singletons and you can replace/consolidate a number of them using a Factory, without losing anything you care about, then that's when you should so do.

As to books, well, there's kind of a canon.

chaos
  • 115,791
  • 31
  • 292
  • 308
0

I thought singletons were good.

Jeff Meatball Yang
  • 34,069
  • 26
  • 85
  • 118
0

Google seems to be convinced that Singletons are a bad idea.

That's not to suggest that everything Google does is perfect or that their every opinion is the end of any argument, but they've gone so far as to write this Singleton detector to root them out. Make up your own mind.

duffymo
  • 293,097
  • 41
  • 348
  • 541