export abstract class SingletonFactory {

class SingletonFactoryImpl extends SingletonFactory { }

Now I can call SingletonFactory.getInstance() and receive an instance, but I also cannot run new SingletonFactory because it is an abstract class. Since the implementation isn’t exported, no one can get to it but the factory.

Although, I have to call out that this pattern would be better with the logic of the factory (somethingUseful()) actually being defined in the Impl class and only the interface being defined in the Factory class itself. It gets the point across.

-Brenton


private static _instance:SingletonClass = new SingletonClass();


Then we can just return the instance:

public static getInstance():SingletonClass {
return SingletonClass._instance;
}


If you call getInstance() first, then trying to call “new SingletonClass()” will fail as desired. But you can’t guarantee what somebody will try to do.

Bastian’s answer handles it, but the extra variable is unfortunate.

Another hacky but workable option is to have the instance method set the variable to undefined instead of null. Then the constructor only works if the instance variable is undefined rather than the default (null). I don’t like it, but it’s the best workaround I can think of.

The real solution is for TypeScript to allow private constructors.

It’s very courius… Thank you!

/**
* Returns the instance of Singleton
*
* @returns object {Singleton}
*/
public static getInstance():Singleton {
if(Singleton._instance === null) {
Singleton.allowInstance = true;
Singleton._instance = new Singleton();
Singleton.allowInstance = false;
}
return Singleton._instance;
}
}


Someone could use your Singleton class like below and assume they have created two different instances. Which they have not, they are both the same object.


var one = new SingletonClass();
var two = new SingletonClass();
// (one===two) does equal true as the same object.
var three = SingletonClass.getInstance();
// three is the same object as one and two.


With coding I find limiting the number of ways you can do something better. Or your documentation will look: “You can do it this way, or this way or this way to accomplish the same task.”


constructor() {
    if(SingletonClass._instance){
       return SingletonClass._instance;
    }
    SingletonClass._instance = this;
}


I tested before posting and it caused the compile error (or seemed to) but have tested again it it doesn’t. I updated to 0.9.1.1 yesterday so it’s possible I tested on 0.9.1 and it was working under that version.

I tried it and I did not get a compile error. I don’t think that is a good approach to enforce the singleton pattern. With your approach I can do the below and there is no compile error. Also they are two different objects. I am using TypeScript 0.9.1.1.


var sing1:SingletonClass = new SingletonClass();
var sing2:SingletonClass = new SingletonClass();
console.log(sing1 === sing2);
// false