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

1. Thou shalt spend more time thinking than coding.
2. Thou shalt never commit a line of code that is unnecessary.
3. Thou shalt never commit code that you do not fully understand.
4. Thou shalt never commit commented out code unless there is another comment explaining why it is commented out.
5. Thou shalt format thy code consistently.
6. Thou shalt always leave code cleaner and more organized than you found it.
7. Thou shalt never do the same thing twice but differently without explicit reason to do so. If you are not sure whether you have broken this rule, see (3).
8. Thou shalt never copy and paste more than two lines of code unless you are moving it.
9. Thou shalt refactor thy code regularly.
10. Thou shalt never rely on the compiler or someone else to test your code.

10 Doctrines of Programming

1. Assume the coder before you didn’t know what he was doing until you understand what he was doing.
2. Always aim to understand someone else’s coder better than they do.
3. A poorly performing application is a broken application.
4. Build your application to handle more mock data than you ever think would be necessary.
5. As soon as you feel comfortable about your code, you have sinned.
6. If you don’t know how long something will take, say you don’t know how long something will take.
7. Revise your estimates regularly.
8. Be explicit and organized in your naming of everything.
9. If your code is not pretty, nobody will want to be intimate with it.
10. Make the next developer love you.

“And thirdly, the code is more what you’d call “guidelines” than actual rules.” – Barbossa

- Josh