04Aug Pipes theory pt. 2

After pondering the matter, an example API for such a function would be:

function subscribe():void {
   Pipes.get("chat pipe").subscribe(callBack);
   // See below for the callBack function that
   // gets executed when a message is sent
}
function callBack(message:*):void {
   // Maybe when creating a pipe, it would be
  //  possible to lock the message type?
}
function sendPipeMessage():void {
   // creates a new pipe is one doesn't exist
   var myPipe:PipeSender = Pipes.get("chat pipe");
   myPipe.send(someObject);
}
function joinOrSplitPipe():void {
   Pipes.get("chat pipe").join("ui pipe");
   Pipes.get("chat pipe").split("ui pipe");
}

So you might be thinking the same thing I was… why use pipes over event listeners??
Well, here are the pros and cons that I can see off-hand…

Pipes function the same as events except:

• Pipes can reach any level of the application… not just parents like events do when they bubble
• Pipes can be setup to enforce a one-way message system to an API or client class
• Pipes can be merged or split
• Pipes can be layered easily by using a new set of unique ids for the pipes. Events, on the other hand, bubble around the application globally climbing up parents which can cause major issues in an application that requires an easy reset, duplication, or tiered structure.

Link to the original article: Pipes theory pt. 1

Author: Jonathan Dunlap Jonathan is an experienced software engineer, sole blogger of JADBOX, author of FlashMVC, humanitarian, and has contracted work for Microsoft, Coke, and Disney.

Tags: theory