I want to point out some reason why Robotlegs makes sense. For someone who does not know Robotlegs: It’s an Actionscript 3 framework that builds upon the Model-View-Control (MVC) code design pattern. In short: You can use it to seperate the logic of your application (controller) from the data (model) and the representation of it (view).
You can find implementations of MVC in divers frameworks and programming languages – frontend and backend alike. When you google MVC pattern you can read tons of articles about the pros and cons.
Communication between Objects made easy
Beside MVC there are two other features I really appreciate about Robotlegs. First, it has a build in event bus. You should know events from Flashs Display List. Objects that get created if the user “does something” with the user interface (e.g. MouseClick). These event objects can bubble up the display list (the hierarchy of nested displayobjects like Sprite or Movieclip). Thats nice as it is but the events are bound to the displaylist. In Robotlegs the objects share an eventdispatcher they can utilize to listen for events or to send events into the framework – and that is not limited to user interface elements nor the displaylist. The benefit is: You do not need to know the actual object that broadcasts the event meaning you do not need a reference to the broadcaster in your listening classes. Just listen to the event bus and everything works.
Robotlegs helps to reduce code
The other thing is automated Dependecy Injection (DI). (Google it for more information). What automatic DI does is it provides your classes with their dependencies. If you have a Car class and that class needs an instance of the Motor class to work properly when getting instantiated Robotlegs does it for you. That means you do not have to write construction code to first get a motor, instantiate it, then create a car and put the motor in it’s constructor. Code instructions like that are called boiler plate code, code with the sole purpose to create and combine objects, code that has no business logic. Sure you have to instruct Robotlegs on startup what objects are created at what time but that is, compared to manual creation and combining, a lot less code.
And it does not make it harder to understand
Some say using frameworks like Robotlegs bloat your code and DI makes it hard to understand what happens where. But these arguments are even more true for individual code. I had to get back to my last bigger project built with Robotlegs after 2 month. I found it really easy to put in new functionality because of the seperation due to MVC and DI. I just wrote another class, pointed out that this class needs an instance of the model when instantiated and was ready to go. Without Robotlegs I would have needed to break apart my code base and look for hooks in my code to put the new class into place – more boilder plate code or even restructuring other classes.
Robotlegs or other frameworks are not made for very very small projects like banner advertising because they naturally put in some kB for the framework classes but if your project is not restricted in that way give it a try. It not only makes your code more flexible but makes you think about object communication in general.
