Abstract Classes and Singleton Pattern

[dzhedzho]

Hello guys, if some of you have been wondering how to create abstract classes in AS3, here is an idea. The following class Abstract cannot be instantiated, however its subclasses can. The Abstract class does not have to be in a package, I just placed itin one so you note the name



package hd{
import flash.utils.getQualifiedClassName;
public class Abstract {
public function Abstract () {
if (getQualifiedClassName(this)=="hd::Abstract") {
throw new ArgumentError("Error 2012: class Abstract cannot be instantiated.");
}
}
}
}


Seems that the common way to do this seems to be

package{
public class CommonSingleton {
private static var instance:CommonSingleton;
public function CommonSingleton (enforcer:SingletonEnforcer) {
}
public static function getInstance ():CommonSingleton {
if (instance==null) {
instance = new CommonSingleton(new SingletonEnforcer);
}
return (instance);
}
}
}
class SingletonEnforcer {
}
However the error message thrown when trying to create object from this class is rather (un)informative
//1136: Incorrect number of arguments. Expected 1.
In addition you can still create an instance using the constructor passing null as parameter. Something which you quite possibly will try while scratching your head over the error above
Well, here is another way to do this


package{
public class Singleton{
private static var instance:Singleton;
private static var direct:Boolean = true;

public function Singleton () {
if (direct) {
throw new Error ("Use Singleton.getInstance() instead");
}
}

public static function getInstance ():Singleton {
if (instance!=null) {
return (instance);
}else{
direct = false;
instance = new Singleton();
direct = true;
return (instance);
}
}
}
}

Cheers

[Felixz]

Instead abstract classes why not using interfaces?
To create Singleton I use this
package {
public class Singleton {
private static const _Instance:Singleton=new Singleton();
public static function get Instance():Singleton {
return _Instance;
}
public function Singleton():void {
if (_Instance) throw new IllegalOperationError("Singleton can not be instantiated!");
}

[dzhedzho]

Well, you can have some things defined in an abstract class, even though that class won't be purely abstract. In addition you can have abstract methods which are protected. You can override those methods in sublclasses but keep them from the public. Well I dunno why one might want to use abstract class, but that's one way to make one.

Your way to make a singleton is kinda cool actually, even though it is not a textbook singleton and the instance is always defined, in practice it is pretty much the same thing :D

[senocular]

Here's some things you need to watch out for. One of the advantages singletons have over static classes is that they can be extended. This means that a) Ideally, you shouldn't be putting singleton instances in static variables since they need to be inherited, and more importantly b) a subclass needs to be able to invoke the singleton superclass constructor. If you're using a class that a subclass will not have access to for constructor validation, instantiation of you're subclass will fail.

Abstract classes, though not supported by the language, are a little easier. For them, you just compare the construcor property of this in the constructor with the class. If the same, throw an error.

With Singletons, you would want to do the same, but a little backwards. Instead of failing with constructor == this, use that only to tell when a singleton check is required. If constructor != this, allow instantiation as super() is being invoked from a subclass. only to make sure that the current constructor call is first make sure the instantiation is occurring within the context of the class instance. At that point, when it is determined you need to validate (not in a superclass) then you could actually use the helper class approach, or others such as a private permit boolean.

[dzhedzho]

Here's some things you need to watch out for. One of the advantages singletons have over static classes is that they can be extended. This means that a) Ideally, you shouldn't be putting singleton instances in static variables since they need to be inherited, and more importantly b) a subclass needs to be able to invoke the singleton superclass constructor. If you're using a class that a subclass will not have access to for constructor validation, instantiation of you're subclass will fail.


Would you care to explain point "a"?

[senocular]

Actually, a is incorrect as I explained it above. I meant to say deferred instantiation is preferred because the use of static properties creates instances of singletons within the class definition. Through the use of static property definitions within the class body, each singleton superclass will inherently have an instance of itself stored in a hidden property. This can create redundancy and potentially lead to more crunch time in the SWF init. Of course, this is usually a preference (and pertinent only in the case of subclassing which was really the "consideration" I was after)