I really like the stricter typing of signals compared to events.  For me, strict typing means that my code is checked by the compiler (instantly, at compile time) as apposed to being checked by the AVM (eventually, at runtime).  I have had countless times where I have seen code fail due to the event types declared in the handler method being wrong, even when the string values are stored as variables instead of using literals. The checking that event handlers are added correctly is not checkable by the compiler.  This means we need to either blindly hope it all works out or rely on testing.

Signals (out of the box) fixes this issue but there is still another issue for me, the contract between an event (also a signal) and its handler.  With events there are two contracts, the event type (the Event.type String) and the event data.  Signals (out of the box) handles the event type issue by moving the name of the type into an interface as a signal, which is a great idea!  The data problem is harder to solve.

There are two checks that should be performed on the data.

The first is validation. At the moment this is limited to type checking.  When you set up a signal, you specify that the signal should be an int, String etc.  I think this is a great start but I think there should be more (optional) validation checks available; range checks for ints and regex checks for Strings.  When these validations fail then the signal should have a built in mechanism to throw an InvalidSignalError.  This would tighten up the robustness of projects using signals and would definitely reduce the amount of code I write.

The second check is verification. This is a lot harder to check but is a much more valuable check to perform. I think this is up to developers to check when developing. I am currently using signals to send messages between objects. I like to keep the implementation of my objects hidden from others so when writing a class I am always mindful of what values are available to other objects. So, when writing a signal I often find myself doing the following:

public class ShowScreenSignal extends Signal
{
private static const MENU:int = 0;
private static const PLAY:int = 1;
...
public function ShowScreenSignal()
{
super(int);
}
public function dispatchMenu():void
{
dispatch(MENU);
}
public function dispatchPlay():void
{
dispatch(PLAY);
}
...
public function isMenu(message:int):Boolean
{
return message = MENU;
}
public function isPlay(message:int):Boolean
{
return message = PLAY;
}
...
}

This means in my controller/mediator I call signal.dispatchPlay() and in my listener/command I check signal.isPlay(message) to check the message. This means nothing knows about the message values other than the signal. I can change the message to be a String without changing any of my controllers/mediators/command. This is better encapsulation. This works really well when using RobotLegs + Signals as you can subtype your command classes and have a condition in your execute method if (message.isPlay(message)).

This is solving one problem. I want to have one signal with many handlers based on the message. eg:

public class ShowPlayCommand extends SignalCommand
{
[Inject]
public var message:int;
[Inject]
public var signal:ShowScreenSignal;
override public function execute():void {
if (!signal.isPlay(message)) {
return;
}
//do something
}
}

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.