Skip to content

Singleton factory

2009 March 27

Juten Tach,

for my upcoming book i’m currently heads down in design patterns. Today i was actually looking for a good example for the proxy pattern, but instead had an idea for a Singleton factory. I know the discussion about Singleton being no good because of global state, bad testability and so on, but let’s just forget this for one moment and look at the implementation idea.

So, what i’m using here, is the not really documented feature of private classes. But today i found an example of a private class in the Adobe LiveDocs, so this made me a little more hopeful, that this feature is not there coincidentally. So if you think, this is too hot, don’t read further. Otherwise, here it goes. First thing i do is, i create an interface, that describes my Singleton:

package {
   public interface ISingleton {
      function get someName():String;
      function set someName(value:String):void;
      function doSomething():void;
   }
}

So, for this example, it is quite small and understandable, i guess. Next thing, i implement the Singleton and i implement a SingletonFactory, both in the same file, that’s why i was talking about private classes:

package {
   public final class SingletonFactory {
      private static var _singletonInstance:ISingleton;
      public static function getInstance():ISingleton {
         if (_singletonInstance == null) {
            _singletonInstance = new PrivateSingleton();
         }
         return _singletonInstance;
      }
   }
}

class PrivateSingleton implements ISingleton {
   private var _someName:String;
   public function get someName():String {
      return _someName;
   }

   public function set someName(value:String):void {
      _someName = value;
   }

   public function doSomething():void {
      trace("Doing something with: " + _someName);
   }
}

So, as you can see, the PrivateSingleton is a private class, declared outside of the package definition, so it is only visible to SingletonFactory, no one else. PrivateSingleton, of course, implements ISingleton. And the SingletonFactory does, what Singletons normally do for themselves, it manages and creates the Singleton. I like that approach, because the responsibilities are separated nicely, the PrivateSingleton doesn’t actually know, that it is a Singleton. Should you ever decide to let it be a normal class, then you simply could put it into its own class file and things would still work, even for the SingletonFactory (although you probably would want to discard it then).

So, to use a Singleton like that, you would do something like this:

var mySingleton:ISingleton = SingletonFactory.getInstance();
mySingleton.someName = "Hans";
mySingleton.doSomething();

Well, that’s it, nothing big, just one more solution for building a singleton. One additional advantage here is, that you get nice compile time errors, when trying to use PrivateSingleton inappropriately. Most AutoCompletions will not even propose the class. Drawback is, you cannot inherit from PrivateSingleton and you still might have that dim feeling, that using private classes might be wrong.

Share this:
  • email
  • Twitter
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Posterous
  • Digg
  • Technorati
  • Slashdot
  • Suggest to Techmeme via Twitter
  • StumbleUpon
  • Reddit
  • Netvibes
  • LinkedIn
  • Mixx
2 Responses leave one →
  1. March 28, 2009

    Ooooh, you are going to meet resistance by publishing about Singletons.
    Anyway one way to overcome the inheritance problem would be by abstraction, but you would lose the lazy instantiation, which is always kind of nice. I blogged about something similar a few weeks ago at
    http://blog.controul.com/2009/02/the-much-dreaded-singleton/

  2. March 28, 2009

    hi Hristo,
    yeah, please note, i’m not a fan of Singletons. I just had this idea about separation of concerns and the fact, that you get compile-time errors with this approach and wanted to write it down.

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS