Cairngorm Patterns: Abstract Delegate
Posted by Steve Brownlee on March 12, 2009Mar 12
Purpose
My intended purpose for the AbstractDelegate class in Cairngorm was two-fold:
- Reduce the number of files needed to manage business events by organizing Delegates into domains
- Make each domain Delegate class as lightweight as possible
Related Posts
Abstract Commands | Abstract Events
Concept
Lightweight Delegate
By extending the AbstractDelegate class, each domain Delegate created by a developer become absurdly lightweight and simple. Basically, it become a series of methods mapped to remote procedure call names.
ProjectDelegate.as
package business.delegates
{
public class ProjectDelegate extends AbstractDelegate
{
public function loadProjects():void
{
send("getProjects", {});
}
public function deactivate(eventData:Object):void
{
send("deactivateProject", eventData);
}
public function createProject(eventData:Object):void
{
send("createProject", eventData);
}
}
}AbstractDelegate Class
The the AbstractDelete class will take care of holding the reference to the application’s data model, and constructing the final RPC with the designated Responder attached.
AbstractDelegate.as
package business.delegates
{
import business.RemoteFactoryLocator;
import flash.utils.getQualifiedClassName;
import mx.rpc.IResponder;
public class AbstractDelegate
{
private var _responder:IResponder;
private var _remoteService:RemoteFactoryLocator = RemoteFactoryLocator.getInstance();
public function AbstractDelegate()
{
if(flash.utils.getQualifiedClassName(this) == "business.delegates::AbstractDelegate")
{
throw new Error("ClassInstantiationException: Cannot create an instance of an abstract class.");
}
}
public function setResponder(responder:IResponder):void
{
_responder = responder;
}
public function send(eventName:String, eventData:Object):void
{
_remoteService.send(eventName, eventData, _responder);
}
}
}So now all of my delegates extend the AbstractDelegate which allows us to write less code for all of these stinking delegates for our application.
The only ramification is that the Commands (see Abstract Command post for example) now have to call the setResponder() method on each delegate.
I like these abstract classes you’ve written about. But what does the RemoteFactoryLocator look like?
The RemoteFactoryLocator class just creates the RemoteObject needed to communicate with my middleware package (usually ColdFusion).
Here’s a snippet of the constructor, and the send() function…
Thanks for the example. In the meantime I came up with a similar class that routes requests to the various HTTPServices I’m using. I do really like how my implementation of the abstract classes is working so far.