Thomas Mueller isn't that an idea for a new expert? It should automatically remove this cr*p and have an option to add the form variable back if needed.
Stefan Glienke There is nothing wrong with singleton. The issues in your link arise from hidden dependencies, not singleton itself. Of course singletons can be abused or not used properly but the same applies to many things. Actually, singletons are even built-in in some languages, e.g. Scala.
Stefan Glienke That "Singletons are Pathological Liars" article has an amusing name, since it starts out with a lie. The second sentence flat-out declares that "a good developer" will (unconditionally) start developing any new feature by writing tests. This is a bunch of nonsense, and anything premised upon such a shaky foundation is therefore automatically highly suspect.
I think the confusion surrounding the blog post Stefan Glienke linked to comes from two sources: . 1) As a few people have pointed out, it's not the Singleton that is a liar, but the APIs -- it's just the Singleton's fault. Hm, hadn't the author even edited the headline to that effect? (Not the URL, though.) . 2) What the author actually meant was that a globally accessible collection of miscellaneous state should be considered harmful in this sense. The confusion probably arose from the fact that such collections, for probably at least the last decade or so, have been implemented as Singletons. Perhaps to such an extent that many younger coders, including the blogger, have come to more or less believe that "Singleton" actually means such a global packaged-state variable.
Mason Wheeler When aiming for high quality code test first approach is the way to go hands down. Sadly its often ignored (even by myself and I mostly regret it at some point). Linas Naginionis And most of the time they are not standalone but merely the "class var part" of the accompanying class.
Stefan Glienke It looks like Misko is confusing global state with global mutable state. These are completely different things. Global state isn't bad at all unless it is mutable.
Linas Naginionis Looks like you are interpreting something into it. Of course he is talking about mutable state. Guess why he says global variable multiple times.
Stefan Glienke But what it has to do with singletons? Singletons are global state but not necessarily global mutable state. His arguments are flawed from the beginning.
Linas Naginionis Are you arguing because you want to argue? Clearly he is not talking about immutability because immutability would not cause different results on different object graphs talking to that immutable state, right?
Which is not what the Singleton pattern is about. There is no notion of immutability in that pattern. It's all about forcing only one instance of a class and prevent manual instantiating. Anyway I think after his session its quite clear that not the singleton implementation itself is the real problem (the fact that you enforce only one instance) but the way people usually collaborate with it. If you are not going through DI you will hard code access to the singleton instance which is the core problem because then you have no way whatsoever to create a seam for testing. When working with classic singletons people don't usually pass them via injection but directly access foo.Instance.doSomething() somewhere deep inside their code (because thats the easiest and most convenient way, right? - just as the one guy asked for his showmessage thing that he can just grab easily everywhere because its a singleton).
Stefan Glienke There is no notion of mutability in Singleton pattern either. Singleton is just a pattern which restricts the instantiation of a class to one object. It doesn't tell you to mutate anything. If people are using something incorrectly, it doesn't make this thing bad. It's just a fact that a lot of people do not understand the benefits of immutability.
Anyway I think after his session its quite clear that not the singleton implementation itself is the real problem (the fact that you enforce only one instance) but the way people usually collaborate with it. : this is what I'm trying to say.
Also, there is no actual difference if someone inside a code calls foo.Instance.doSomething() or new Foo().doSomething(). It's the problem of hidden dependency which was not injected, not the Singleton itself.
First of all I learned about 90% of what I know about testing and writing testable code from Misko Hevery.
I have huge respect for that guy, but at the end you have to use your own head and not just follow others no matter how smart they are and how right they are in 99% percent of cases. Because nobody is 100% right (except my husband, of course ;-)
function Sum(a, b: Integer): Integer; begin Result := a + b; end;
I can absolutely test above function. There is nothing untestable about it.
Same thing goes with singletons (and other things) It is never black and white situation, there is plenty of shades of gray in between.
Which brings me back to statements like "Singletons are bad". It is very broad dogmatic statement that actually tells nothing.
For starters it does not even say what is definition of singleton. For me singleton includes variety of patterns including ones that may not be considered as true singletons, even though in production code you will create only single instance of class.
Also above statement tells nothing about why are singletons bad, and how to avoid that particular bad side and use the in a way that is not as bad. Because whether we like it or not everything can be abused and sometimes you have to choose between less of two evils.
Because after all writing software is not just theory but also practice. You have to adapt to less than perfect OS-es, tools, languages, time frames and million other requirements. And there is no absolute "true path" in doing so.
Dalija Prasnikar I absolutely agree with the "not just follow others no matter how smart they are and how right they are in 99% percent of cases" - that is why I usually dislike absolute statements like "never do ..." or "always do ..." (or at least put an asterisk on it saying: in 99% of the cases...) ;)
As for the static method thing - your Sum is a leaf method but in theory it could turn into a non leaf method (maybe someone thinks it will be better to call some web service that does the calculation or whatever) which then could complicate testing.
"We're gonna need another Timmy!"
ReplyDelete... global variables or singletons ...
ReplyDeleteSo who invented Application?
ReplyDeleteA. Bouchez why singletons pattern is something wrong ? Can you elaborate ?
ReplyDeleteRules are meant to be broken.
ReplyDeleteIsn't auto declaration like
ReplyDeletevar Form1 :TForm;
not global variable declaration?
Stéphane Wierzbicki Amongst a bazillion other articles I found this one very informative (including the 2 follow up ones linked at the bottom): http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
ReplyDeleteIn short: singletons are one of the worst enemies of testability and modularity.
What do you mean "should"? We shoot them, period.
ReplyDeleteАлексей Кулаков that's the second thing I delete after creating a new form (after these totally unnecessary {xxxxx declarations} comments).
ReplyDeleteThomas Mueller and also turn off auto create forms/data modules
ReplyDeleteThomas Mueller isn't that an idea for a new expert? It should automatically remove this cr*p and have an option to add the form variable back if needed.
ReplyDeleteDaniela Osterhagen hm, a lot of effort just to save a few key strokes. Sounds like fun ;-)
ReplyDeleteShoot me now ;-)
ReplyDeleteMy mobile apps are singletons galore....
Stefan Glienke There is nothing wrong with singleton. The issues in your link arise from hidden dependencies, not singleton itself. Of course singletons can be abused or not used properly but the same applies to many things. Actually, singletons are even built-in in some languages, e.g. Scala.
ReplyDeleteSingletons cannot be tested properly. You are always coupled to the state of the singleton. So the singleton itself are the hidden dependencies
ReplyDeleteAgustin Ortu Of course singletons can be tested. They cannot be tested if you design them badly. The same rule applies to other things as well.
ReplyDeleteThis also applies to class vars, which are exactly the same, except for the new fancy clothing?
ReplyDeleteStefan Glienke That "Singletons are Pathological Liars" article has an amusing name, since it starts out with a lie. The second sentence flat-out declares that "a good developer" will (unconditionally) start developing any new feature by writing tests. This is a bunch of nonsense, and anything premised upon such a shaky foundation is therefore automatically highly suspect.
ReplyDeleteStéphane Wierzbicki singletons are global variables in disguise, meant for an oop fashion défilé.f
ReplyDeleteI think the confusion surrounding the blog post Stefan Glienke linked to comes from two sources:
ReplyDelete.
1) As a few people have pointed out, it's not the Singleton that is a liar, but the APIs -- it's just the Singleton's fault. Hm, hadn't the author even edited the headline to that effect? (Not the URL, though.)
.
2) What the author actually meant was that a globally accessible collection of miscellaneous state should be considered harmful in this sense. The confusion probably arose from the fact that such collections, for probably at least the last decade or so, have been implemented as Singletons. Perhaps to such an extent that many younger coders, including the blogger, have come to more or less believe that "Singleton" actually means such a global packaged-state variable.
Mason Wheeler When aiming for high quality code test first approach is the way to go hands down. Sadly its often ignored (even by myself and I mostly regret it at some point).
ReplyDeleteLinas Naginionis And most of the time they are not standalone but merely the "class var part" of the accompanying class.
Everyone that was confused by the article might watch his clean code talk: https://www.youtube.com/watch?v=-FRm3VPhseI
Stefan Glienke It looks like Misko is confusing global state with global mutable state. These are completely different things. Global state isn't bad at all unless it is mutable.
ReplyDeleteLinas Naginionis Looks like you are interpreting something into it. Of course he is talking about mutable state. Guess why he says global variable multiple times.
ReplyDeleteStefan Glienke But what it has to do with singletons? Singletons are global state but not necessarily global mutable state. His arguments are flawed from the beginning.
ReplyDeleteLinas Naginionis Are you arguing because you want to argue? Clearly he is not talking about immutability because immutability would not cause different results on different object graphs talking to that immutable state, right?
ReplyDeleteStefan Glienke I am arguing because you are blaming singletons when you should blame global mutable state.
ReplyDeleteWhich is not what the Singleton pattern is about. There is no notion of immutability in that pattern. It's all about forcing only one instance of a class and prevent manual instantiating.
ReplyDeleteAnyway I think after his session its quite clear that not the singleton implementation itself is the real problem (the fact that you enforce only one instance) but the way people usually collaborate with it. If you are not going through DI you will hard code access to the singleton instance which is the core problem because then you have no way whatsoever to create a seam for testing. When working with classic singletons people don't usually pass them via injection but directly access foo.Instance.doSomething() somewhere deep inside their code (because thats the easiest and most convenient way, right? - just as the one guy asked for his showmessage thing that he can just grab easily everywhere because its a singleton).
Stefan Glienke There is no notion of mutability in Singleton pattern either. Singleton is just a pattern which restricts the instantiation of a class to one object. It doesn't tell you to mutate anything. If people are using something incorrectly, it doesn't make this thing bad. It's just a fact that a lot of people do not understand the benefits of immutability.
ReplyDeleteAnyway I think after his session its quite clear that not the singleton implementation itself is the real problem (the fact that you enforce only one instance) but the way people usually collaborate with it. : this is what I'm trying to say.
Also, there is no actual difference if someone inside a code calls foo.Instance.doSomething() or new Foo().doSomething(). It's the problem of hidden dependency which was not injected, not the Singleton itself.
First of all I learned about 90% of what I know about testing and writing testable code from Misko Hevery.
ReplyDeleteI have huge respect for that guy, but at the end you have to use your own head and not just follow others no matter how smart they are and how right they are in 99% percent of cases. Because nobody is 100% right (except my husband, of course ;-)
So I don't agree with everything he said, or at least with what I think he said. For instance he claims that static methods and procedural code cannot be tested. Which is not completely true. http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/
For instance
function Sum(a, b: Integer): Integer;
begin
Result := a + b;
end;
I can absolutely test above function. There is nothing untestable about it.
Same thing goes with singletons (and other things) It is never black and white situation, there is plenty of shades of gray in between.
Which brings me back to statements like "Singletons are bad". It is very broad dogmatic statement that actually tells nothing.
For starters it does not even say what is definition of singleton. For me singleton includes variety of patterns including ones that may not be considered as true singletons, even though in production code you will create only single instance of class.
Also above statement tells nothing about why are singletons bad, and how to avoid that particular bad side and use the in a way that is not as bad. Because whether we like it or not everything can be abused and sometimes you have to choose between less of two evils.
Because after all writing software is not just theory but also practice. You have to adapt to less than perfect OS-es, tools, languages, time frames and million other requirements. And there is no absolute "true path" in doing so.
Dalija Prasnikar I absolutely agree with the "not just follow others no matter how smart they are and how right they are in 99% percent of cases" - that is why I usually dislike absolute statements like "never do ..." or "always do ..." (or at least put an asterisk on it saying: in 99% of the cases...) ;)
ReplyDeleteAs for the static method thing - your Sum is a leaf method but in theory it could turn into a non leaf method (maybe someone thinks it will be better to call some web service that does the calculation or whatever) which then could complicate testing.