Flex and Singletons

One of the major problems with building your generic Singleton is that you cannot extend it. Once you’ve locked yourself into a particular implementation you cannot create a new version since all the old code is referencing the old version, in the old package structure, with a specific name. You cannot swap out singletons. Or can you?

The way Adobe built the Singleton class and PopUpManager, PopUpManagerImpl, IPopUpManager, etc. used to bother me a lot, because it didn’t make any sense and the purpose of having all those classes – when they could have used a standard singleton pattern – was never explained.

Well I finally got it, and it does make sense and I’m tempted to tell all of our Flex developers working on our framework to begin using the pattern established by the Flex mx.core.Singleton Class.

The Old Way

The standard Singleton approach is to do something like this:

package
{
  public class MyStandardSingleton
  {
    public function MyStandardSingleton()
    {
      if (_instance)
      {
        throw new Error("Singleton violation.");
      }
    }

    private static var _instance : MyStandardSingleton;

    public function getInstance() : MyStandardSingleton
    {
      if (!_instance)
      {
        _instance = new MyStandardSingleton();
      }

      return _instance;
    }
  }
}

The problem with this approach is that one cannot ever create a MyStandardSingleton2 and move all the old code to using it without, well, updating all the old code and every single reference. That’s not good. Especially if you have lots of layered libraries using that Singleton.

The Right Way

The solution is found by using the approach provided by Adobe:

1) Create an interface representing the functionality of your Singleton (e.g. IMySingleton)

2) Create an implementation of that interface (e.g. MySingletonImpl implements IMySingleton)

3) Register your implementation with mx.core.Singleton, using the interface class name (with package) as the name:

Singleton.registerClass("my.package.IMySingleton", MySingletonImpl);

4) Create a class that doesn’t implement the interface (e.g. MySingleton) but has the same methods as public static. Then in each of those methods, call Singleton.getInstance(…) and ask for the string name you provided in (3), cast as the interface from step (1), and call the same method:

public static function myMethod(param1:DisplayObject):Object
{
  return (Singleton.getInstance("my.package.IMyInterface") as IMyInterface).myMethod(param1);
}

Conclusion

Now, if you ever want to create a new implementation of IMySingleton, just make sure you register it with mx.core.Singleton before the old implementation and all your code will just work.

So what would you do if you wanted to create your own IPopUpManager to override the functionality of the Flex PopUpManager? Simply register it with Singleton under the name “mx.managers::IPopUpManager” before the Flex framework does.

Unfortunately, I’m too busy to figure all that out right now, so maybe someone else can enlighten me as to the timing.

- Josh

Advertisement
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.