CoreHub came about as a result of my being assigned to research the Pipes library for a work project. Said project intended to use Flex modules and PureMVC MultiCore. Pipes is a utility library created by the author of PureMVC to enable communication between modules after they are loaded. It does so by using the so-called pipes and filters design pattern, a complicated plumbing metaphor for message relaying involving a great many objects and quite a bit of boilerplate. The purpose of all of this, supposedly, was to maintain encapsulation among the various modules, to make absolutely certain their code remained independent of one another.
Eventually, though, I realized that even Pipes depends on breaking encapsulation at certain points through shared static namespaces — otherwise, the various joiner classes don’t know how to connect to one another. At that point, I wondered why one should even bother with all the extra classes and overhead. As long as we’re breaking the encapsulation principle in a limited way, why not just use a Singleton and make sure that it’s the only point where the modules share code?
So I did. Using what I’d learned from PureMVC, I created a library where one Singleton is used as a central communication hub for all the different modules. Following Pipes’ example, I also built in support for basic message queues and message prioritization.
Simple? Yes. Could anyone who understood enough about PureMVC have easily done the same on their own? Absolutely. Did I do it anyway? Yeah, mostly just as a way to experiment with writing my own libraries and releasing them on GitHub.
In the end, of course, one might just as easily use SWFBridgeEvents or something similar to communicate between modules. That’s what we wound up doing on the work project I mentioned. All the same, at least I learned from the process of putting all of this together.