Singleton design pattern should be used discreetly. Many of us are building API’s and using singletons as a means to create a global object that can be accessed across the application.Here’s why you should use singleton discreetly:

1. In many cases, using singleton is an anti-pattern;
2. The singleton may be considered as an anti Action Script, since Action Script 3.0 doesn’t support private or protected constructor;
3. With programming, it is usually not recommended to

use global objects, since it is hard to test them and the developer has to make assumptions regarding the application and how they will be used.

The main source of the problems is that using the singleton pattern makes the classes tightly coupled instead of loosely coupled, meaning that you can only test a few classes together rather than each of the classes at a time, as you should.

Before I go into a discussion on when is it a good idea to use the singleton pattern, I think it’s a good idea to show how the singleton is used in Action Script 3.0.

What is the singleton pattern?
The singleton pattern is used to restrict instantiation of a class to one object. The pattern keeps a private constructor to insure that the class was created only once.

Singleton in Action Script 3.0:
Action script does not support the option to declare constructor as private or protected inside of a package, which causes a design pattern problem, since any option you choose will be considered workaround or a “hack”.

One popular option is to use the inner classes, meaning creating another class inside of the package to behave as the private constructor, such as in the example below:

package {

	public class Manager
	{
		/**
		 * var to be used by the singleton pattern to return the instance of the class.
		 */
		private static var manager : Manager;

		/**
		 * Internal constructor. Should not be called from outside this class.
		 *
		 * @param enforcer	Enforce the creation of one class only.
		 *
		 */

		public function Manager(enforcer:AccessRestriction)
		{
			// TODO: throw exception
			if ( enforcer == null )
			{
				throw new Error("Manager error enforcer input param is undefined" );
			}
		}

		/**
		 * Method function to retrieve instance of the class
		 *
		 * @return The same instance of the class
		 *
		 */
		public static function getInstance() : Manager
		{
			if( manager == null )
				manager = new Manager(new AccessRestriction());

			return manager
		}
	}
}

class AccessRestriction {}

To view the source code as text file click here.

So when should you use the singleton design pattern?
Here’s a singleton recommended check list:

1. Singleton should be used in cases where only one object is needed to coordinate actions and/or events across the application;
2. The application will always use the object in the same way;
3. It doesn’t really matter to the client what’s going on in the rest of the application, meaning that the singleton object is independent.

If you can confirm the check list, than it’s a good candidate to use the singleton pattern.

Have fun designing!