This is a complementary article to Antipimp’s “I could care less what they say.”. Read that first if you have a moment, then come back here and finish up.  Take your time, it’s worth it. 

.

.

Now, let’s talk about the other side of the fence.

Once you get the awesome job that Asshat Antipimp lined up for you, trust me when I say that no one gives a flip how many lines of code you wrote, or what awesome application framework you used. They care that you solved their problem and that it won’t break in a month.

Software folks are notorious for their.

• Oddball personalities
• A penchant for useless, esoteric knowledge of science fiction and fantasy literature
• Ability to completely disregard all social convention
• Expediency in stinking up a room
• Many other curious behaviors..

My least favorite trait of many of my colleagues is their mistaken belief that other people give a shit about the technology. Well, actually, they do, but only when it doesn’t work. Things can be sunshine and roses and kisses and hugs for years, but trust me, when you write an application that doesn’t work, then be prepared to kiss your technology goodbye – or end up on the street.

The 99% of the world that doesn’t know how to write a ternary operation sees software as a means to an end, and that’s it folks. Writing software is “magic” to them and I hate to see application developers exploit that fact.

They aren’t amazed by your ability to use an ORM package.

They don’t care that you squeezed a few more cool aspects into your IoC architecture.

Then even don’t care that you’ve taken the painstaking effort to apply industry-standard usability practices to make it easier for them to work with it.

They. just. want. it. to. work.

Therefore, if you find yourself taking 20 minutes to explain to the eyes-glazed-over, bored-beyond-tears business folks how awesome you are, then it’s time to shut the hell up, sit down, and let them bicker about the fact that you used the wrong shade of blue in the application header.

Your job is to solve problems and make the lives of other easier. They don’t understand what you do, and no matter how long you try to explain it to them, they’ll still only care about having a picture of their dog on their web site.

It is interesting, for me, to note that AOP and Service Oriented Architectures (SOA) started to gain momentum around the same time, and yet the interest, and advancements, in SOA quickly outdistanced those for AOP.

In my opinion, this is because the practical applications for AOP are minimal, while the concepts of SOA can quickly and easily be grasped and implemented in many business environments.

I can’t really find any white papers from someone who’s actually implemented a project with this kind of architecture, so it all seems stalled in the theoretical phase still. Of course, I can’t think of a project that I’m working where we could use this.

I still find it fascinating, though.

What Is An Agent?
Properties of Agents
Agent Oriented Software Engineering
A Taxonomy for Autonomous Agents
Jam! Agent Architecture

The intended purpose for the AbstractEvent class in Cairngorm was three-fold:

1. Reduce the number of files needed to manage business events by organizing Events into domains
2. Implement a callback feature so that a view can specify another action to perform upon the successful completion of an event
3. Make each domain event class as lightweight as possible

Related Posts

Abstract Commands | Abstract Delegates

Concept

To accomplish these goals, each domain event (e.g. ProjectEvent, PaymentEvent, etc.) would be polymorphic (kinda) in that there is no longer just one identifier designated with the EVENT_ID constant. In addition, I wanted to abstract as much functionality and classification as possible into a common class that each domain event would extend.

Lightweight, Polymorphic Event Class

Here’s an example of a domain event. It has three public identifiers – CREATE_PROJECT, LOAD_PROJECTS, DEACTIVATE_PROJECT- and has no logic other than to pass its constructor’s arguments to AbstractEvent.

ProjectEvent.as

package business.events
{
   import com.adobe.cairngorm.control.CairngormEvent;

   public class ProjectEvent extends AbstractEvent
   {
      public static const CREATE_PROJECT:String = "createProject";
      public static const LOAD_PROJECTS:String = "getProjects";
      public static const DEACTIVATE_PROJECT:String = "deactivateProject";

      public function ProjectEvent(type:String, data:Object = null, callbacks:Array=null)
      {
         super(type, data, callback);
      }
   }
}

AbstractEvent Class

The AbstractEvent class itself isn’t much more complicated at all. It simply has three public variables to hold the type of the event, an object containing key/value pairs for the data, and the reference to the callback function in the view (if specified).

AbstractEvent.as

package business.events
{
   import com.adobe.cairngorm.control.CairngormEvent;

   public class AbstractEvent extends CairngormEvent
   {
      public var callbacks:Array = null;

      public function AbstractEvent(type:String, data:Object = null, callbacks:Array=[])
      {
         super(type);

         this.data = data;
         this.callbacks = callbacks;
      }
   }
}

Example View – Projects

Here’s some snippets of code from my project view. One piece of functionality is for a user to disable a selected project from a list in an AdvancedDataGrid. When the user clicks on the “Disable Project” button, the btnDeactivateProject_Click() function fires and creates a new Project event in which the loadProjects() function is specified as the callback function.

Projects.mxml

private function btnDeactivateProject_Click(e:Event):void
{
   var thisProject:Project = gridProjects.selectedItem as Project;
   new ProjectEvent(ProjectEvent.DEACTIVATE_PROJECT,
            {project:thisProject},
            [loadProjects]).dispatch();
}

public function loadProjects():void
{
   new ProjectEvent(ProjectEvent.LOAD_PROJECTS).dispatch();
}

<mx:Button id="btnDeactivateProject"
	click="btnDeactivateProject_Click(event)"
	x="10" y="393"
	label="Deactivate Project"/>

Mapping Events to Commands

Your controller logic doesn’t change. The only difference is that you’re using one domain event, with specified identities, mapped to different Commands.

Controller.as

package business
{
   import business.commands.*;
   import business.events.*;
   import com.adobe.cairngorm.control.FrontController;

   public class Controller extends FrontController
   {
      public function Controller()
      {
         super();
         addCommand(ProjectEvent.LOAD_PROJECTS, LoadProjectsCommand);
         addCommand(ProjectEvent.CREATE_PROJECT, CreateProjectCommand);
         addCommand(ProjectEvent.DEACTIVATE_PROJECT, DeactivateProjectCommand);
      }
   }
}

The intended purpose for the AbstractCommand class in Cairngorm is three-fold:

1. Further implementation of a callback feature – in conjunction with the AbstractEvent – so that a view can specify other actions to perform upon the successful completion of business event
2. Create a Responder object for the Delegate to use
3. Make each Command class as lightweight as possible

Related Posts

Batch Commands | Abstract Events | Abstract Delegates

Concept

Standard, Responseful Command

Below is an example Command in my system, it extends AbstractCommand which in turn implements the ICustomCommand interface. To make the Command responseful, an array of functions is passed from the Event to the Command, which will execute them upon success (see more below). Here’s an example call:

new EmployeeEvent(EmployeeEvent.GET_DETAILS,
         {employee_id:params.empID},
         [showEmployeeDetails, updateEmployeeGraph])

To implement a very basic command, it is only required to set the delegate property to a new instance of the appropriate Delegate class, and then invoke the needed method. The AbstractCommand will automatically create a new Responder object and assign it to the delegate.

LoadProjectCommand.as

public class LoadProjectCommand extends AbstractCommand
{
   private var _model:ModelLocator = ModelLocator.getInstance();

   override public function execute():void
   {
      delegate = new ProjectDelegate();
      (delegate as ProjectDelegate).loadProject(invoker.data);
   }

   override public function commandSuccess(event:Event):void
   {
      if (event.result.success)
      {
         _model.project = (event as ResultEvent).result.data;
         notifyInvoker();
      }
   }
}
}

The invoker object is a reference to the original Event that was called, and to get it assigned as a property of the Command, I extended the FrontController class so that it is assigned before the Command is executed.

protected function executeAbstractCommand(event:AbstractEvent):void
{
   var commandRef:Class = getCommand(event.type);
   var commandToExecute:ICustomCommand = new commandRef();

   commandToExecute.invoker = event;
   commandToExecute.execute();
}

AbstractCommand Class

This class is straightforward and handles the tedious aspects of creating a Command. The notifyInvoker() method simply loops through the array of callback functions – if they exist – and runs them.

AbstractCommand.as

public class AbstractCommand
{
   private var _callbacks:Array = null;
   private var _invoker:AbstractEvent = null;
   private var _delegate:AbstractDelegate = null;

   public function AbstractCommand() { }
   public function execute():void { }
   public function commandSuccess(event:Event):void { }
   public function commandFault(event:Event):void { }

   public function set delegate(d:*):void
   {
      _delegate = d;
      _delegate.setResponder(new Responder(commandSuccess, commandFault));
   }

   public function get delegate():*
   {
      return _delegate;
   }

   public function set invoker(e:AbstractEvent):void
   {
      _invoker = e;
      if (e.callbacks != null) _callbacks = e.callbacks;
   }

   public function get invoker():AbstractEvent
   {
      return _invoker;
   }

   public function notifyInvoker(info:Object = null):void
   {
      if (_callbacks != null)
      {
         for (var i:uint = 0; i < _callbacks.length; i++)
         {
            var callback:Function = _callbacks[i];
           (info != null) ? callback.call(this, info) : callback.call(this);
         }
      }
   }
}

ICustomCommand Interface

ICustomCommand.as

package business.commands
{
   import business.events.AbstractEvent;
   import flash.events.Event;

   public interface ICustomCommand
   {
      function commandSuccess(event:Event):void;
      function commandFault(event:Event):void;
      function execute():void;
      function set invoker(event:AbstractEvent):void;
      function set delegate(delegate:*):void;
   }
}

Abstract Commands

Basic Cairngorm Commands

In the base implementation of the Cairngorm micro-architecture, events and commands are mapped on a 1-1 basis. For every invoker (event) you have to specify one command in your controller.

public function Controller()
{
   super();
   addCommand(TeammateEvent.LOAD_TEAMMATES, LoadTeammatesCommand);
   addCommand(EffortEvent.LOAD_TYPES, LoadEffortTypesCommand);
   addCommand(ProjectEvent.LOAD_PROJECTS, LoadProjectsCommand);
   addCommand(TeammateEvent.LOAD_TEAMMATE_ROLES, LoadTeammateRolesCommand);
   ...
}

For most cases, this is perfectly fine, but in a data-heavy model, such as the one being built for my current application, I need to initialize the application and fire off many individual events in order to load my model with base data.

// Load all teammates in the database for display in the reports tab
new TeammateEvent(TeammateEvent.LOAD_TEAMMATES).dispatch();

// Load all effort types
new EffortEvent(EffortEvent.LOAD_TYPES).dispatch();

// Load all projects
new ProjectEvent(ProjectEvent.LOAD_PROJECTS).dispatch();

// Load all roles
new TeammateEvent(TeammateEvent.LOAD_TEAMMATE_ROLES).dispatch();

...

Batch Commands

In order to avoid having to dispatch n events for n commands to be executed, I would rather map 1 event to n commands and have them fired off in sequence. Then, if I need a batch of commands to fire, I only need to dispatch one event, instead of the 4 I used in the example above.

new ApplicationEvent(ApplicationEvent.LOAD_MODEL).dispatch();

Unfortunately, Cairngorm does not allow this, so I had to extend the basic architecture. I created a addCommands() function that maps a single event to multiple commands as an array.

public class Controller extends ExtendedFrontController
{
   public function Controller()
   {
      addCommands(ApplicationEvent.LOAD_MODEL, [LoadTeammatesCommand,
                                LoadEffortTypesCommand,
                                LoadProjectsCommand,
                                LoadTeammateRolesCommand,
                                ...]);
   }
}

Extended Controller Class

Here’s the code that I’ve come up with so far. This is working fine, but there still some things I plan on implementing in the future.

ExtendedFrontController.as

public class ExtendedFrontController extends FrontController
{
   public function ExtendedFrontController()
   {
      super();
   }

   public function addCommands(commandName:String, commandRefs:Array, useWeakReference:Boolean = true):void
   {
      if(commands[ commandName ] != null)
      {
         throw new CairngormError( CairngormMessageCodes.COMMAND_ALREADY_REGISTERED, commandName );
      }

      if (commandRefs == null)
      {
         throw new Error("The commandRefs argument to addCommands() is null");
      }

      commands[commandName] = commandRefs;

      for (var priority:uint = 0; priority < commandRefs.length; priority++)
      {
         CairngormEventDispatcher.getInstance().addEventListener(commandName, executeCommands, false, priority, useWeakReference);
      }
   }

   protected function executeCommands(event:AbstractEvent):void
   {
      var commandsToInitialise:Array = getCommands(event.type);
      var commandRef:Class;

      for (var i:uint = 0; i < commandsToInitialise.length; i++)
      {
         commandRef = commandsToInitialise[i];
         var commandToExecute:ICustomCommand = new commandRef();
         commandToExecute.execute(event);
      }
   }

   protected function getCommands(commandName:String):Array
   {
      var commands:Array = commands[commandName];

      if ( commands == null )
         throw new CairngormError( CairngormMessageCodes.COMMAND_NOT_FOUND, commandName );

      return commands;
   }
}

Call me a junkie, that’s fine, but this stuff works. I’ve said many times in the past that the whole purpose of using design patterns, code frameworks, and application architectures should be to reduce the code I write (as time progresses), make an application easier to extend, and reduce the cost of turnover.

After quickly learning what the Cairngorm architecture had to offer, I noticed several gaps that needed to be filled. One of which was the inordinate amount of files that are created using the base patterns (which I alleviated with my abstract classes for Event, Command, and Delegate). Another gap is that it doesn’t have a view mediator. That’s the one feature from the PureMVC framework that I actually was a huge fan of.

Mediators

You see, PureMVC uses a Mediator pattern in order to provide a mechanism by which views could interact with the business logic, as well as with each other, while remaining ignorant of the man behind the curtain. Keeping the views decoupled from the model is good – especially with my apps – because subtle changes to the data model happen often, and while a good part of that is handled in the business logic, it often bubbles up to the UI model as well.

I am a Command, I am an Island

Another value feature that other frameworks have is that ability for a View – via a Mediator – to actually know if a Command was successful or not. Gasp! With the base Cairngorm implementation, the only way to perform an action on success of a Command was in the Command itself. Very bad, otherwise you end up with situations that call for SaveProjectAndReloadModelCommand in which you do one action and then immediately call another Command, and SaveProjectWithNoModelReloadCommand for when you don’t need to do the second Command.

A Command should be as insular as possible. It should never directly call another Command.

Responseful Commands

My way around this was to implement a function callback feature in the Event and Command abstract classes.

When an Event is dispatched from a View, the name of a local function is passed as an argument. The Command consumes this function reference and then runs it if the execution was successful.

Tested in the Field

Sure, theory is fine, but how does all this work when actually writing a Flex app? Well, I put that to the test just the other day. An app I’m working needed a significant enhancement and change. After changing the database model, I was able to crank out the business logic, and three views in Flex in which users could create new items, deactivate/activate them, and a few other doo-dads in just under 40 minutes.

Conclusion

Don’t be afraid to enhance a framework or code architecture with your own ideas. Trust yourself and your ideas because you’re smart, too.

My intended purpose for the AbstractCommand class in Cairngorm was two-fold:

1. Implement a callback feature so that a view can specify another action to perform upon the successful completion of an event
2. Make each Command class as lightweight as possible

Related Posts

Batch Commands | Abstract Events | Abstract Delegates

Concept

Standard, Responseful Command

Here’s an example Command in my system, it extends AbstractCommand and implements the ICustomCommand interface – which simply enforces a commandSuccess() and commandFault() method be present.

When the execute() method is invoked, the callback function property of the domain event is assigned by calling the setCallbackFunction() of the AbstractCommand, then the standard process of instantiating the proper delegate happens.

Now that the Command has a reference to the callback function (if it exists), in the commandSuccess() method, we simply call the AbstractCommand’s notifyCaller() method which executes that function.

DeactivateProjectCommand.as

package business.commands
{
   public class DeactivateProjectCommand extends AbstractCommand implements ICustomCommand
   {
      private var _model:ModelLocator = ModelLocator.getInstance();

      public function execute(event:CairngormEvent):void
      {
         setCallbackFunction((event as ProjectEvent).callbackFunction);

         var delegate:ProjectDelegate = new ProjectDelegate();
         delegate.setResponder(new Responder(commandSuccess, commandFault));
         delegate.deactivate((event as ProjectEvent).eventData);
      }

      public function commandSuccess(event:ResultEvent):void
      {
         if (event.result.success)
         {
            notifyCaller(event.result.data.project as Project);
         }
      }

      public function commandFault(event:FaultEvent):void { }
   }
}

AbstractCommand Class

This class is straightforward and simple. It simply contains the setCallbackFunction() and notifyCaller() methods with a private class member _callback.

AbstractCommand.as

package business.commands
{
   public class AbstractCommand
   {
      private var _callback:Function = null;

      public function setCallbackFunction(value:Function):void
      {
         if (value != null) _callback = value;
      }

      public function notifyCaller(info:Object = null):void
      {
         if (_callback != null)
         {
            if (info != null)
            {
               _callback.call(this, info);
            } else {
               _callback.call(this);
            }
         }
      }
   }
}

ICustomCommand Interface

This interface simply enforces the implementation of the commandSuccess() and commandFault() methods.

ICustomCommand.as

package business.commands
{
   import com.adobe.cairngorm.commands.ICommand;
   import mx.rpc.events.FaultEvent;
   import mx.rpc.events.ResultEvent;

   public interface ICustomCommand extends ICommand
   {
      function commandSuccess(event:ResultEvent):void;
      function commandFault(event:FaultEvent):void;
   }
}

My intended purpose for the AbstractEvent class in Cairngorm was three-fold:

1. Reduce the number of files needed to manage business events by organizing Events into domains
2. Implement a callback feature so that a view can specify another action to perform upon the successful completion of an event
3. Make each domain event class as lightweight as possible

Related Posts

Abstract Commands | Abstract Delegates

Concept

To accomplish my goals, each domain event (e.g. ProjectEvent, PaymentEvent, etc.) would be polymorphic (kinda) in that there is no longer just one identifier designated with the EVENT_ID constant. In addition, I wanted to abstract as much functionality and classification as possible into a common class that each domain event would extend.

Lightweight, Polymorphic Event Class

Here’s an example of a domain event. It has three public identifiers – CREATE_PROJECT, LOAD_PROJECTS, DEACTIVATE_PROJECT- and has no logic other than to pass its constructor’s arguments to AbstractEvent.

ProjectEvent.as

package business.events
{
   import com.adobe.cairngorm.control.CairngormEvent;

   public class ProjectEvent extends AbstractEvent
   {
      public static const CREATE_PROJECT:String = "createProject";
      public static const LOAD_PROJECTS:String = "getProjects";
      public static const DEACTIVATE_PROJECT:String = "deactivateProject";

      public function ProjectEvent(type:String, data:Object = null, callback:Function = null)
      {
         super(type, data, callback);
      }
   }
}

AbstractEvent Class

The AbstractEvent class itself isn’t much more complicated at all. It simply has three public variables to hold the type of the event, an object containing key/value pairs for the data, and the reference to the callback function in the view (if specified).

AbstractEvent.as

package business.events
{
   import com.adobe.cairngorm.control.CairngormEvent;

   public class AbstractEvent extends CairngormEvent
   {
      public var eventType:String = "";
      public var eventData:Object = new Object();
      public var callbackFunction:Function = null;

      public function AbstractEvent(type:String, data:Object = null, callback:Function = null)
      {
         super(type);
         eventType = type;
         eventData = data;
         callbackFunction = callback;
      }
   }
}

Example View – Projects

Here’s some snippets of code from my project view. One piece of functionality is for a user to disable a selected project from a list in an AdvancedDataGrid. When the user clicks on the “Disable Project” button, the btnDeactivateProject_Click() function fires and creates a new Project event in which the loadProjects() function is specified as the callback function.

Projects.mxml

private function btnDeactivateProject_Click(e:Event):void
{
   var p:Project = gridProjects.selectedItem as Project;
   var event:ProjectEvent = new ProjectEvent(
                                  ProjectEvent.DEACTIVATE_PROJECT,
                                  {project:p},
                                  loadProjects);
   event.dispatch();
}

public function loadProjects():void
{
   var projectEvent:ProjectEvent = new ProjectEvent(ProjectEvent.LOAD_PROJECTS);
   projectEvent.dispatch();
}

<mx:Button id="btnDeactivateProject"
	click="btnDeactivateProject_Click(event)"
	x="10" y="393"
	label="Deactivate Project"/>

Mapping Events to Commands

Your controller logic doesn’t change. The only difference is that you’re using one domain event, with specified identities, mapped to difference Commands.

Controller.as

package business
{
   import business.commands.*;
   import business.events.*;
   import com.adobe.cairngorm.control.FrontController;

   public class Controller extends FrontController
   {
      public function Controller()
      {
         super();
         addCommand(ProjectEvent.LOAD_PROJECTS, LoadProjectsCommand);
         addCommand(ProjectEvent.CREATE_PROJECT, CreateProjectCommand);
         addCommand(ProjectEvent.DEACTIVATE_PROJECT, DeactivateProjectCommand);
      }
   }
}

My intended purpose for the AbstractDelegate class in Cairngorm was two-fold:

1. Reduce the number of files needed to manage business events by organizing Delegates into domains
2. 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 already had a nice AOP class for each of these scenarios, so all I had to do was add the __type__ column to the array of structures, and I was good. The test results below seem logical… except for the first set of testing 50 rows. Converting the query results into an array of structs using a simple function call to another component was actually SLOWER than using AOP or converting to DTOs.

Besides that anomaly, the performance hit for using ColdSpring AOP proxies and using DTOs is clearly visible as you add more data.