Eamonn Faherty

Background Reading
The creation method pattern

The Problem?
You want to use objects that are created else where and are of a set type but the implementations may vary.

Examples?
SocketManager, or any thing that needs to be replace during unit testing.

How?
The constructor of my complex object:

public class CharacterFactory {

	public static var factory : NonPlayerCharacterFactory;

	public static function getAPlayer() : IPlayer {
		return factory.getAButton();
	}
}

The using of the creation method:

var player:IPlayer = CharacterFactory. getAPlayer();

Why is it good?
• It is easy to understand; it is a simple pattern that needs little extra code. It builds on the singleton pattern, which is well known.
• You can get objects without knowing how they are created or where they come from.
• You can share objects without the users of the factory knowing the objects are shared.

Why is it bad?
• It is confusing to read code where objects are not being created directly.
• Debugging is hard, as you have to know what was in the factory when you used it in order to know what object you have.

Further Reading
Read about the IOC pattern.

More
Factories are great! They allow you to define scope for your application. This means that you can set a testing scope when you are running unit tests. The involves setting the factories used in your factory to a test factory which provides test doubles. Changing the scope of the factories outside of your application means that you test your code without making any special changes.

Background Reading
The factory method pattern

The Problem?
You have a complex object, which has a lot of arguments in its constructor or you always want to construct the object using different sets of parameters.

Examples?
Socket Manager

How?
The constructor of my complex object:

public function ComplicatedButton(colour:uint, mouseOverColour:uint, mouseOutColour:uint) {
	_mouseOverColour = mouseOverColour;
	_mouseOutColour = mouseOutColour;
	setUpGraphics(colour);
addEventListeners();
}

The using of the creation method:

var redButton : ComplicatedButton = ComplicatedButton.getRedButton();
var blueButton : ComplicatedButton = ComplicatedButton.getBlueButton();

Why is it good?
• It is easy to understand; it is a simple pattern that needs little extra code. It builds on the singleton pattern, which is well known.
• Anyone using one of the creation methods to create the object is guaranteed to have an object in an identical state as the other users of the method.
• Objects that complicated or a lot of constructor parameters can be simplified.

Why is it bad?
• The class now has two responsibilities, the main purpose of the class plus the instantiation of its instances.
• The class can often grow in size as the creators in declared inside the class. This makes the class harder to read for a developer.

Further Reading
Read about the factory patterns.

More
Creation methods are a great first move towards using factories. Their concept is easy to grasp and doesn’t require much extra code. The class can grow quite big, quite quickly but it is up to you to spot when the acceptable size has been passed for you to put your refactoring hat on. I would use them when I have a graphical component that accepts integer colours as parameters or when I have components that need a lot of initial set up. In the example above I have colours specified as integers. To ensure that all of the buttons considered to be red or blue are the same shades of red or blue I protect users of my ComplicatedButton by adding creation methods with the colours hard coded. Once I have more than one group of setups I would refactor, replacing the creation method with a factory method.

Background Reading
Read about the singleton

The Problem?
You want to have multiple instances of a singleton and want global access to them all. This may be because the objects use groups of resources, such as different groups of sounds, or because the objects need a lot of configuration, such as currency converters, or need global access, an event dispatcher.

Examples?
Currency converter, sound controller, global event dispatcher

How?
The Multiton:

public class SocketManagerMultiton {
	private static var _instaces : Dictionary;
	public static const CHAT : String = "CHAT";
	public static const WEATHER : String = "WEATHER";

	public static function getInstace(instance:String) : SocketManagerMultiton {
	ensureInstanceExists(instance);
		return _instaces[instance];
	}

private static function ensureInstanceExists(instance:String) : void {
		if (_instaces == null) {
			_instaces = new Dictionary();
		}
		if (_instaces[instance] == null) {
			_instaces[instance] = new SocketManagerMultiton();
		}
	}

	public function send(message : String) : void {
	}
}

Example Use:

var chatSocket : SocketManagerMultiton = SocketManagerMultiton.getInstace(SocketManagerMultiton.CHAT);
chatSocket.send("hello world");

var weatherSocket : SocketManagerMultiton = SocketManagerMultiton.getInstace(SocketManagerMultiton.WEATHER);
weatherSocket.send("HOW_IS_THE_WEATHER");

Why is it good?
• It is easy to understand; it is a simple pattern that needs little extra code. It builds on the singleton pattern, which is well known.
• See singleton pattern for other good points.

Why is it bad?
• It tightly couples the classes that use the multiton to the fact that they are using a multiton.
• See singleton pattern for other bad points.

Further Reading
Read about the factory and inversion of control patterns.

More
Multitons are a way of grouping Singletons. They share the benefits and carry the problems that Singletons have. They are good for classes that use a lot of resources such as socket connections or classes that cache things. They do make code harder to refactor and very difficult to unit test but if follow the suggestions I made in the Singleton post then you can limit your pain, a bit anyway! If you are going to use a multiton make sure you use String constants as I did above. It is easy to make typing mistakes when using String literals. Also the constants can be meaningful, as they are in my example.

Background Reading
None

The Problem?
You want to ensure you have only a single instance of an object and want global access to it. This may be because the object uses a resource, such as sounds, or because the object needs a lot of configuration, such as a currency formatter, or needs global access, an event dispatcher.

Examples?
Currency formatter, sound controller, global event dispatcher

How?
The Singleton:

package singletonpattern {

	/**
	 * @author eamonn faherty
	 */
	public class SocketManagerSingleton {
		private static var _instace : SocketManagerSingleton;

		public static function getInstace() : SocketManagerSingleton {
			ensureInstanceExists();
			return _instace;
		}

		private static function ensureInstanceExists() : void {
			if (_instace == null) {
				_instace = new SocketManagerSingleton();
			}
		}

		public function send(message : String) : void {
		}
	}
}

Example Usage:

package singletonpattern {
	import common.Example;		

	/**
	 * @author eamonn faherty
	 */
	public class SingletonPatternExample extends Example {

		public function SingletonPatternExample() {
			var socket : SocketManagerSingleton = SocketManagerSingleton.getInstace();

			socket.send("Hello world");
		}
	}
}

Why is it good?
• It works well; if you use an instance protector then you can be sure that only a single instance will exist.
• It is well understood; it is widely used in the actionscript world.
• It is easy to understand; it is a simple pattern that needs little extra code.
• It is easy to implement; actionscript allows us to check the caller of a method and allows us to use private classes.

Why is it bad?
• It tightly couples the classes that use the singleton to the fact that they are using a singleton.
• It is not possible to extend the singleton class if you wanted to add functionality.
• You cannot use your singleton class again; you cannot extend it or reuse it with composition.
• If you are unit testing a class that uses a singleton you need to add some code to your singleton to make testing possible.

Further Reading
Read about the factory and inversion of control patterns.

I recently did my first public talk! It was at LFPUG (London Flash Platform UserGroup).

Here are the details

I think it went really well. I had some very kind feedback via email and twitter and also on the night in person!

A few people have requested that I upload the examples I used and the slides so here they are.

Over the next few weeks I am going to be posting example patterns with more information, in more depth than I did on the night.

If you want me to cover a pattern please post a comment with the pattern name and I will bump it up in the list.