Copy link to clipboard
Copied
Hey all,
I am looking at the singleton design pattern and trying to really understand what is going on here. But I have some questions that it would seem my logic and/or the way I am reading this is wrong. Take the following code for example
package
{
public class Singleton
{
private static var _instance:Singleton;
public function Singleton(pvt:PrivateClass) {
}
public static function getInstance( ):Singleton
{
if(Singleton._instance == null)
{
Singleton._instance=new Singleton(new PrivateClass( ));
trace("Singleton instantiated");
}
return Singleton._instance;
}
}
}
class PrivateClass
{
public function PrivateClass( ) {
trace("Private class is up");
}
}
As I look at this, it seems that the ability for a class to instantiate and or dataytpe its self would not be prudent. I see it as “I instantiate an instance of myself, that instantiates another instance of myself and so on. A reflection of a same reflection type scenario.
I Sort of see it like this:
package
{
public class Singleton
{
private static var _instance:Self;
public function Singleton(pvt:PrivateClass) {
}
public static function getInstance( ):Self
{
if(Self._instance == null)
{
Self._instance=new Self(new PrivateClass( ));
trace(I have instantiated my self");
}
return Self._instance;
}
}
}
class PrivateClass
{
public function PrivateClass( ) {
trace("Private class is up");
}
}
I know with the if statement stops it from instantiating its self, but if I remove it, then would that not cause problems? Am I just looking at this completely wrong?
Oh and another question on this is how is the "PrivateClass" a private class when it has a public constructor? Would the class really be an Internal Class?
thanks
Copy link to clipboard
Copied
the most common use of a class is to create an instance of the class. there's nothing imprudent about that.
the idea behind the singleton class is to allow only one instance of the class.
the above comments relate to your first code snippet. your second snippet doesn't make sense. the first error is there is no Self class.
and all constructors have to be public. that class should probably be internal, though.
Copy link to clipboard
Copied
I hope someone here will present a strong case for Singleton in AS3. I don't see, despite searching for the answer for several years, any use of it. Static methods and properties can be easily used instead of Singleton "pattern'. In a way, true Singleton is not possible in AS3 (unlike in Java).
The instance pased into Singleton constructor is, so called, singleton enforcer. This means that one shouldn't be able to pass this instance explicitly because enforcer class is, sort of, obscure and one has to have an access to it but one, presumably, has not, etc. Well, it is not. There are several ways to overcome this.
So, Singleton is like a congress of North Korean communist party. Everyone makes believe that it is valid and it works but, in reality, the majority is still hungry. In other words, looks like a total BS to me.
Please, please, please someone prove finally that I am wrong!!!!
Copy link to clipboard
Copied
lol.
i never thought i would have heard that from you, andrei. there have been many occasions when i've created a class that should be a singleton class. but because i'm not making the class publically available i have no need to make the class fool-proof (because i don't consider myself a fool). i know the class should only be instantiated once and that's enough. i don't need an error message to remind me.
on the other hand, some people (like g skinner) that make (very useful) classes publically available may use the singleton class to help prevent less knowledgeable people from screwing up. that's the only usefulness i've seen.
Copy link to clipboard
Copied
"i never thought i would have heard that from you, andrei"
Please elaborate more to make me sleep well. Why did not you expect it from me? 🙂
"on the other hand, some people (like g skinner) that make (very useful) classes publically available may use the singleton class to help prevent less knowledgeable people from screwing up. that's the only usefulness I've seen."
Actually, I see this thing working when packages are distributed to a big development team in case of a large scale application. But ONLY if this kind of class is a very abstract top level entity. But, again, in 99.99% of cases it is just a theory as far as Flash applications are concerned...
On the other hand... neah... I don't see any use of it (I just have one too many Bombay Sapphire martinis with olives straight up).
Copy link to clipboard
Copied
Please elaborate more to make me sleep well. Why did not you expect it from me? 🙂
i thought you were a proponent of formal class structure and imagined you were someone that employed architectural patterns in your projects.
Copy link to clipboard
Copied
"i thought you were a proponent of formal class structure and imagined you were someone that employed architectural patterns in your projects."
I am big on classes-based architecture. But I am short on design patterns. Although there are extremely valuable concepts out there but as guidelines - not as Holy Grail.
I am very happy to read "architectural patterns" - not design patterns. This is because in my mind the former represents idea and latter - rigid structure. I mean, not all the applications that can use, for example, MVC concept will benefit from squeezing into out of the box pattern-based frameworks like pureMVC.
Back to Singleton, I actually think there are at least two more cases it may have sense to remedy static properties/methods shortcomings in the AS3 context. One is to use native to AS3 EventDispatchers. Another - to emulate "singularity" of Stage - I mean to limit top level display object container to one. In all other cases static things are more than enough.
The funny thing about so called Singleton in AS3 is that it still uses at least one static method when instance is requested. Feels like a hack to me.
Copy link to clipboard
Copied
I thought about more general usage of Singular in AS3.
Whenever object subclasses some "inheritance chain" - it makes total sense to me. Looks like a rule of thumb can be formulated as "If class' native properties and methods are used - make them static, otherwise - use Singleton pattern."
So, I am warming up to it 🙂
Copy link to clipboard
Copied
I read an interesting blog post a couple years ago which has had me on the fence about singletons ever since.
http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
There are definitely valid arguments on both sides. As has been eluded to in this thread, they make sense if they make sense. I think it was Skinner who said, "Singletons are the new global." He was half kidding I'm sure.
Typically I use them as libraries for things like TextFormats or other re-usable objects. Never as a data model or service. When AS3 is concerned, singleton == hack. If you understand that and are ok with it, I don't see an issue.
Lately however I'm in love with RobotLegs approach to the singleton concept. Treat instances as singletons, but never actually write one.
Find more inspiration, events, and resources on the new Adobe Community
Explore Now