Below are a bunch of references basically showing that I am not alone in my belief that Singletons are globals in the sense intended in the discussion that links here. See SingletonPatternTermAsCoined
for the origin of the word 'global'. It is the same as the origin of the term "Singleton Pattern".
''You can start the list of URLs with: SingletonPattern
, that's what wikis are for.
''' Not sure what you mean here. If you mean this page should start with that, fine by me. If you mean that all of this stuff should be added to the SingletonPattern
, I respectfully disagree as another (long time) wiki user, administrator and even hacker on some popular php wiki code. I broke this out because it is extraneous except for the specific purpose it was put here (see below). As you intimate, it does not directly add substance to that page, so I did not put it there. Very long pages rather defeat the nature of wikis. The page that refers to this is overlong. Long pages are contrary to accepted HCI practices. A friend of mine did his doctoral thesis on this stuff and helped me with the HCI component of some of my sites. Long pages also place an unwelcome burden on the server. I also admin a lot of servers. Small pages good.
Naturally, as a guest, I will not presume to tell you how to run your show. I merely state the reasons for my behavior. If you remain adamant, you are welcome to edit, delete, whatever. [GuyWhoReopenedTheSingletonCanOfWorms
But if two people say the same thing that does not make it twice as true, it doesn't make it twice as false either.
I categorically agree with what you say above. Sadly, it is not actually relevant to the discussion.
You may not have seen the referring page -- SimpletonPattern
. This page is establishing vernacular usage. As per the method used directly in the OED, the meaning of words is established by usage, consensus, etc. If you mistake my meaning, what I am saying is that in this instance the more people that use a term in a certain way the more the term takes that meaning. This page was in response to someone baldly asserting that (for the purposes of the discussion) Singletons did not have the negative quality of being global. At least as defined by the community I come from (as illustrated on this page), Singletons (BY DEFINITION) have the quality of being global. Be that as it may, even if it was only 'relatively global' or whatever term you use to describe it, a Singleton is OF NECESSITY BY NATURE beyond its proper scope. You have a right to your opinions, but I humbly suggest that as a professional programmer for decades I have the right to my opinions as well. For further clarification of this point, see SingletonPatternTermAsCoined
The "global point of access" part is simply wrong. The wiki page SingletonPattern
is correct in describing it as : "If a system only needs one instance of a class, and that instance needs to be accessible in many different parts of a system, you control both instantiation and access by making that class a singleton.". That is the correct explanation of the singleton pattern. The "global access" is optional, and doesn't apply to all uses of the singleton pattern. Some designs provide for local singletons. If many people are sloppy and make more global singletons then necessary, that's a different matter.
According to who, exactly? Anyone can jump right onto the page you describe and define that term any way they like. It appears they actually have. Whatever the case, as I have described in agonizing detail elsewhere, the entire basis of SingletonPattern
is corrupt. It is simply poor programming practice.
And then you don't need to sprawl over new pages when existing pages suffice. Wiki already has SingletonPattern
. Have you considered the arguments already made and think you have something new to add ? ''
Well, actually, I rather think I have something old
to add. Again, see see SingletonPatternTermAsCoined
and the many links below re the actual meaning of SingletonPattern
. See also SingletonPatternDeprecated
''' Finally (they all sigh), If you read the referring page carefully, you will note that I am objecting to a scoping issue. Note the title of this page: ForThisPurposeSingletonsAreGlobals
. You (or whoever is incrementally redefining 'Singleton') seem to wish to avoid the issue by 'hacking the meaning of the term' and splitting hairs with semantics. By its very purpose of being, a singleton moves something that should be out of scope into scope. Again, For This Purpose the scope is Global. It depends upon the language, but in those languages that have scoping rules (java, C/C++, descendants of Algol, etc), scoping is all about visibility. 'Global' in that sense is a relative thing. Things can be global across the Internet, within an Enterprise, a subnet, a computer, and operating system, a service, an embedded object, a code package, an object, a function or a scoping block. At any of those scoping levels if something is visible beyond its proper scope it inherits the evils of 'globalness' (relative to its distance from 'home'). Even by your definitions, I am sure you would agree that the majority of the scopes above would be considered 'global' with respect to an object method or static function.
We shall have to agree to disagree. Those who truck in variables beyond scope, multiple points of entry or exit, laziness with scoping mechanisms (like braces on if statements), confusions between levels of abstraction, etc are bound to learn the hard way. I was hoping that perhaps adding another voice of sanity to this wacky debate might save at least one poor programmer some grief.
"Singleton .. Intent .. Ensure a class has only one instance, and provide a global point of access to it."
Singleton Considered Stupid
Friends: don't let friends use Singletons!
Singleton is probably the most widely used design pattern. Its intent is to ensure that a class has only one instance, and to provide a global point of access to it.
So, what is a Singleton class ? A class that assures a maximum of ONE object of its type at a given time and provides a global access point to this object is a Singleton class.
Singleton gives you a global access point like a global variable, but is intended to reduce overhead by not initiating the object until it is called, unlike global variables that would be initiated at startup even if they are never used and guarantees that there is only one instance in memory.
Problem number two: globals. Try not to use globals. At all. If you're using MVC, having your model accessible off of a singleton global class is very handy. That way no matter where you are in your code you can just do Model.somethingSomething to affect the model. Though this makes coding very easy, this is a problem when your app gets loaded.
The solution: pass "context" around:
Singleton provides a global, single instance
The Singleton pattern
In Design Patterns, the authors describe the Singleton pattern like this:
Ensure a class has only one instance, and provide a global point of access to it.
Singleton .. Intent .. Ensure a class has only one instance, and provide a global point of access to it.
Global Variables in Java with the Singleton Pattern
Singleton Pattern: One Global Object
Stateful singletons still offer one advantage over straight global variables -- they have encapsulation. Granted, it's not any better than having a global object
To quote Kent Beck: �The real problem with Singletons is that they give you such a good excuse not to think carefully about the appropriate visibility of an object.� [Joshua, p. 116]
In the words of Martin Fowler: �remember that any global data is always guilty until proven innocent.� [PEAA, p. 482-483]
Definition of Singleton
The singleton pattern is defined as a means to �ensure a class has one instance, and provide a global point of access to it�
[DP, 127]. Essentially, you have restricted the creation of the class to a single point in the code. For most implementations, that point will also provide the global access to the singleton.
The Great Disease: Singletonitis
So, what is Singletonitis? It's a disease discovered by one Joshua Kerievsky. He enumerated his discovery in his book Refactoring To Patterns. To summarize, it is when a person becomes addicted to the Singleton pattern.
Unfortunately, this disease is easily spread amongst the untrained. It those infected with this disease take many months or years to be cured, and many will be infected for life. Because of this, we urge you to avoid singletons at all cost. Think of all of those poor unfortunate newbies you will be saving from a tragic demise.
Why do we have a Data Cancer
The Top Five to avoid it
Avoid static fields.
If you need static fields, think about clean-up.
Try to avoid Singletons. If Singletons make sense, do clean-up.
There are several problems with the Singleton design pattern, the worst ones being:
Singletons make unit testing difficult. In particular, singletons tend to assume a lifetime longer than a single unit test; so they're difficult to reset ready for the next test.
They can't be reused. If you find that a different module can make use of your controller class, you might be tempted to give it a separate instance to play around with. But you can't because it's a Singleton. But when you decide to change it, that leads to the next problem...
They're difficult to extend (assuming you want the subclass to also be a separate instance). Because the instance is got via a static method, it can't easily be overridden with a more specialized singleton. This can be worked around, but not particularly elegantly.
Any code which uses the class will naturally assume the class can only have a single instance, even if it doesn't need to. Changing cardinality could lead to all sorts of nasty bugs and breakage.
As you can see, Singletons restrict your design. By their very nature (and intent) they lock you in to a single instance of a class. While this might be okay at the time, it restricts future refactoring of the design. Once a class has become a Singleton and other classes have begun using it, it can be difficult to make it a non-Singleton (multiton?), as the rest of the design will have evolved around the concept.
Change leads to breakage: but changing cardinality can lead to carnage. You'll find that much of your code makes subtle assumptions based on the fact that certain classes have only one instance. In short, overuse of Singletons leads to sloppy design.
It is noteworthy here that almost all object oriented languages have singletons. Often global constants, such as a null object (Smalltalk: nil, the sole instance of class UndefinedObject
); often global wrappers around system services (Java AWT Toolkit.getDefaultToolkit is a polymorphic singleton wrapping the platform-dependent windowing system in a platform-independent API, wrapped further by the whole AWT, and then by Swing...)
Any OO language with classes being first class objects has a bunch of immediate singletons. Java (Foo.class class literals) and Smalltalk (any class name in code is a class literal) for starters. Of course, Smalltalk is full of global variables (in SystemDictionary?
's sole instance, another singleton named Smalltalk) anyway, and pollutes a single global namespace with all class names to boot. Class variables in these languages are therefore global variables of sorts.