Quote:Original post by davepermen
well, it's so hard to understand me.
what defines the difference of a singleton to a global is the singletonity, a.k.a. the single-instance-feature.
the question is, when, ever, is that feature in any form useful.
Original post by the_eddQuote:Original post by TheMac
I am going through this in my head and I can't understand why for one, singletons are hard to test in your unit tests.
You might be able to unit test a singleton, but you cannot unit test anything that uses that singleton.
Not true, at work I replaced the way we do encryption with an encryption/decryption manager (singleton), changed the code in one class to one single call to the manager, and the unit test that was already in place continued to run with no problems.
In other words, I replaced some complex boilerplate code with the manager, and our tests still worked, so why are people saying its hard or impossible to test?
Quote:Original post by davepermenQuote:Original post by Antheus
Ever tried unit testing a database application where you need to test DROP statement? In common design where database access is singleton or global hard-coded, accidentally running such test without changing the configuration will wipe the production system. So how do you test it automatically?
Much easier if systems are not coupled.
QFT.
not exactly a DROP statement, but in general. once it's a hot database, with money-data in, and all, and you have to test stuff around, have fun if you can't just switch the database easily. i first had, in all my apps, a singleton connection (just so damn easy in .net). i learned the quite hard way (no dataloss in the end in the database) that this isn't how it should go :)
singletons are just bad. everyone who doesn't understand this still has to learn a lot in clean, save, proper programming.
i do use globals sometimes. i do use global functions sometimes. but never singletons.
edit:
i have found quite some places where globals can be handy (in small scale apps, that is). i never found one point, where a singleton has any gain over a global. if i thought it may be that way, taking the global away and making it a locally pass-around object was always simpler to implement, less to think about, and then, 100% working and debuggable and testable.
Quote:Original post by TheMac
How are singletons bad programming, but globals are not?
Quote:Original post by ToohrVyk
I think you have a problem with the generally accepted meaning of principles. A principle is something you can follow while writing code. It makes sense to follow the open-closed principle, because it dictates that some things should be done ("your classes should be open to extension even if they are closed to modification"), but it doesn't make sense to "follow" polymorphism...
Quote:Polymorphism and encapsulation are generally thought to be object-oriented tools, something you can use to build great object-oriented programs, but which you can also use to write messy heaps of developer pain—principles being what guides you to use the tools to achieve the former instead of the latter.
Quote:Original post by davepermen
but sometimes they fit your needs. question is, when do singletons fit your need and globals don't? singletons are much more limiting, when do you gain from it?
Quote:i'm all for limiting stuff in your code, that's why you shouldn't use globals.
Quote:but i never limit classes, i always limit objects.
Quote:limiting functionality is just bad.
Original post by TheMacOriginal post by the_eddQuote:Original post by TheMac
I am going through this in my head and I can't understand why for one, singletons are hard to test in your unit tests.
You might be able to unit test a singleton, but you cannot unit test anything that uses that singleton.Quote:
Not true, at work I replaced the way we do encryption with an encryption/decryption manager (singleton), changed the code in one class to one single call to the manager, and the unit test that was already in place continued to run with no problems.
In other words, I replaced some complex boilerplate code with the manager, and our tests still worked, so why are people saying its hard or impossible to test?
Just because your test still passes does not mean that it was or is a proper unit test. Do you factor out the encryption mechanism by using a mock or some other sort of unit testing dependency injection? If not, then you are not performing an actual unit test, merely a test.
Also, what you have created is a global function, which can be created in many different ways other than the singleton pattern, and I would say that in fact, the singleton pattern is the most naive way to achieve a global function. And as many people have said, if you are not keeping state with your singleton, then the difficulty of unit testing diminishes (as you can replace global functions through dependency injection in your testing if you designed it well), but it also shows that you have completely missed the purpose of the singleton pattern as well.
