By lightweight we mean that it’s a handy pocket knife that can get a lot of jobs done, not a complete toolkit that can attend to every eventuality. Robotlegs has a very focussed scope—facilitating the relationships between the objects in your application.
By framework we mean that it provides a skeleton for your application. The majority of your code will be specific to your project, but underneath that unique body sits a set of bones which are broadly the same each time. These bones allow the different parts of your application to function as a coherent system.
The term framework is used very loosely in our community, referring to anything from The Flex Framework to jQuery or Ruby on Rails. The definition of a framework is simply:
A reusable set of libraries or classes for a software system.
This doesn’t really tell you much at all about what any particular framework does and doesn’t do.
In an AS3 application, objects can communicate and cooperate in two different ways:
One object has a direct reference to another object, and it calls its API (its public methods) to communicate and cooperate with it.
In AS3, this takes the form of the event system. One object can
listen for a message, in the form of an
Event, on another object. Typically this
means that the listening is done directly, but it doesn’t have to
be—the display list or a shared reference to an
allow this to be done in a more loosely coupled way (meaning that the
objects don’t directly have to know about each other).
Robotlegs helps make both of these forms of communication and cooperation easier to set up, meaning that you can spend more time focussed on the individual pieces of your app—which are usually the interesting and unique parts—and less time focussed on how you’re going to connect them together.
Providing objects with their dependencies (other objects they need to use) instead of the objects creating or fetching their own dependencies.
Encapsulating individual pieces of application logic inside dedicated objects instead of spreading all of that logic through a single controller class.
Using a dedicated object as a mailman/woman to facilitate communication between different objects, instead of those objects talking directly to each other.
If these are new to you, don’t worry; we’ll cover them in plenty of detail in this book. Even if you’re familiar with them, you may find that the Robotlegs implementation varies a little from how you’ve used them in the past; solution patterns don’t dictate code, they describe an approach to a common problem.
Before you can choose the right framework for your project, you should really consider whether you need to use a framework at all. Many great programmers argue against using frameworks—the main objection being that given a shiny ‘Golden Hammer’, everything looks like a nail. On the Robotlegs help forum, one of the most common responses we give to newcomer questions is, “You really don’t need to use the framework to do that.” Here are some of the significant pros and cons of frameworks in general, as we see them:
|Consistency||Framework learning curve|
|Common understanding brings easier collaboration||Terminology confusion|
|Peer-reviewed solutions||Performance tradeoffs|
|A well-tested skeleton||Framework coupling|
|Less code to write||‘Black box’ code is hard to debug|
Frameworks encourage you to take the same approach to similar problems each time you solve them. This reduces the ‘cognitive overhead’ you carry for your architecture, because you only have to think about the parts that are unique and interesting.
If you need to bring in additional coders on your project, they should be able to follow your codebase if they have an understanding of the framework. Someone who is familiar with Robotlegs will quickly feel at home in any Robotlegs project.
The back-and-forth between the contributors to an open-source framework encourages the honing of good solutions that are flexible enough to solve a range of problems for different programmers. This flexibility also benefits your application.
Assuming your chosen framework comes with a full set of unit tests (and it should), you can be confident that it behaves as intended. Be aware that tested never equals perfect, but with good test coverage it should be possible to fix bugs that are found without breaking functionality. The tests are also a concise guide to the expected behavior of each class in the framework.
Frameworks generally allow you to swap a large quantity of complex code for a smaller amount of simpler ‘boilerplate’ code. (This shouldn’t be your primary motivation for picking a framework, as writing code is only a small fraction of how we spend our time.)
You have to learn to translate your problems to the solutions that the framework authors favored. This means changing your coding and architecture behavior, which requires you to do some brain rewiring. That’s not trivial when you’re trying to solve problems that are unique to your application at the same time.
Words are significantly more effective than just pointing and grunting, but where you don’t share the framework’s exact definition of a term, you can suffer from increased cognitive overhead; “That’s not what I would have meant by mediator”.
Code that is flexible is rarely as fast in execution as code that is finely tuned to solve one specific problem.
You may find that you’re unable to reuse your code in projects which don’t use the same framework.
When you’re using third party utilities, including frameworks, it’s hard to be confident about whether bugs are being caused by your own custom code, by the way you’re using the framework or by a problem with the framework itself.
The Robotlegs originators had used other frameworks in the past, and were really conscious of the potential pitfalls when they set out to create Robotlegs, so you should find less of the downside when using Robotlegs than you might normally find when adopting a new framework.
When you ask someone why they first chose to use a framework to build their code, their first response may well be that it allowed them to build the same application with ‘less code’. In particular, we value not having to write the same-old long-hand boilerplate code (code that is repeated throughout your codebase without much purpose) over and over.
// you have to specify all 5 parameters just to get access to weak listeners something.addEventListener(MouseEvent.CLICK, clickMovesMenu, false, 0, true);
Less boilerplate is certainly one of the benefits of using a framework, but it’s worth bearing in mind that the amount of time we spend actually writing code is pretty small. We spend the majority of our time thinking about the code we’re writing. If there are productivity gains to be made in reducing word count, there surely must be bigger gains in reducing ‘thought count’.
So, while Robotlegs does pay close attention to the amount of boilerplate required, we hope you’ll experience greater benefits in your brain than your fingers.