Talk:Singleton
| (4 intermediate revisions by 4 users not shown) | |||
| Line 2: | Line 2: | ||
A force that encourages me to have a singleton is when I'd otherwise have to list it as an argument in heaps and heaps of method calls. I think low code verbosity should be considered as a force that would encourage use of certain patterns. [[User:Lindsay|Lindsay Kay]] | A force that encourages me to have a singleton is when I'd otherwise have to list it as an argument in heaps and heaps of method calls. I think low code verbosity should be considered as a force that would encourage use of certain patterns. [[User:Lindsay|Lindsay Kay]] | ||
| + | |||
| + | Hmmm... When dealing with singletons in an inheritance hierarchy, [[DBC]] applies. I.e. if the superclass is a singleton it forces all other subclasses to comply (be singletons also); however turning a subclass into a singleton only imposes this on the subclass (and its subclasses)... I found that to be an interesting thought. Do you agree? Or is it completely obvious? Also, if you wish to subclass, due to class encapsulation you have to make the constructor protected. This breaks the singleton pattern as it is then technically possible to instantiate multiple instances within the same package. --[[User:Matthew Harward|Matthew Harward]] 23:35, 4 August 2009 (UTC) | ||
| + | |||
| + | I believe you are correct Matthew, subclassing causes problems with the singleton pattern. It seems to me that singleton should only be used for classes that will never be subclassed. I am not sure that you can enforce that through code though, maybe something that somehow checks the parent of a new instance? Personally, I think that makes singleton limited in application, since it can behave like a wrapper for global variables. I also question the example given of a Print Spooler class needing to be a singleton. Sure, having only one seems correct, since it is the effectively a gateway to the lower system calls and thus the hardware, but why would you need that to be global in an OO program? Wouldn't you use something like an interface for other classes to implement when required? Perhaps I have misinterpreted what is meant by that example. The only case I can think of where you may want the versatility of global access is if you had an operator class such as 'Multiply'. The Multiply object may have extra fancy checks/functions/conversions/whatever that make it more usable than just the standard * call. Multiply could be used in some accounting software that can do direct currency conversions on the fly (thank you Kent Beck), thus having it globally accessible may be advantageous, until you start running multiple threads perhaps, then it may have to be something more like [[Flyweight]]. --[[User:Douglas Wall|Douglas]] 03:34, 16 September 2009 (UTC) | ||
| + | |||
| + | Just to show how complicated a singleton implementation can get when you want it to be subclassable and having things like thread safety: [http://www.garyrobinson.net/2004/03/python_singleto.html Python Singleton by Gary Robinson]. The comments include simpler examples of singletons. --[[User:TobiW|TobiW]] 05:25, 16 September 2009 (UTC) | ||
Latest revision as of 03:17, 25 November 2010
Created the page. --Elliot Fisher 01:41, 19 September 2008 (UTC)
A force that encourages me to have a singleton is when I'd otherwise have to list it as an argument in heaps and heaps of method calls. I think low code verbosity should be considered as a force that would encourage use of certain patterns. Lindsay Kay
Hmmm... When dealing with singletons in an inheritance hierarchy, DBC applies. I.e. if the superclass is a singleton it forces all other subclasses to comply (be singletons also); however turning a subclass into a singleton only imposes this on the subclass (and its subclasses)... I found that to be an interesting thought. Do you agree? Or is it completely obvious? Also, if you wish to subclass, due to class encapsulation you have to make the constructor protected. This breaks the singleton pattern as it is then technically possible to instantiate multiple instances within the same package. --Matthew Harward 23:35, 4 August 2009 (UTC)
I believe you are correct Matthew, subclassing causes problems with the singleton pattern. It seems to me that singleton should only be used for classes that will never be subclassed. I am not sure that you can enforce that through code though, maybe something that somehow checks the parent of a new instance? Personally, I think that makes singleton limited in application, since it can behave like a wrapper for global variables. I also question the example given of a Print Spooler class needing to be a singleton. Sure, having only one seems correct, since it is the effectively a gateway to the lower system calls and thus the hardware, but why would you need that to be global in an OO program? Wouldn't you use something like an interface for other classes to implement when required? Perhaps I have misinterpreted what is meant by that example. The only case I can think of where you may want the versatility of global access is if you had an operator class such as 'Multiply'. The Multiply object may have extra fancy checks/functions/conversions/whatever that make it more usable than just the standard * call. Multiply could be used in some accounting software that can do direct currency conversions on the fly (thank you Kent Beck), thus having it globally accessible may be advantageous, until you start running multiple threads perhaps, then it may have to be something more like Flyweight. --Douglas 03:34, 16 September 2009 (UTC)
Just to show how complicated a singleton implementation can get when you want it to be subclassable and having things like thread safety: Python Singleton by Gary Robinson. The comments include simpler examples of singletons. --TobiW 05:25, 16 September 2009 (UTC)
