ActionScript Developer's Guide to Robotlegs

Chapter 1. Robotlegs is a lightweight framework for ActionScript 3

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.

What does Robotlegs actually do?

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.

Robotlegs is a communication-and-cooperation framework

In an AS3 application, objects can communicate and cooperate in two different ways:

Direct conversation

One object has a direct reference to another object, and it calls its API (its public methods) to communicate and cooperate with it.

Passing messages

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 IEventDispatcher can allow this to be done in a more loosely coupled way (meaning that the objects don’t directly have to know about each other).

Figure 1-1. Direct conversation vs passing messages between objects

Robotlegs helps with direct conversations and message passing

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.

Robotlegs makes use of three object-oriented architectural patterns

Automated Dependency Injection

Providing objects with their dependencies (other objects they need to use) instead of the objects creating or fetching their own dependencies.

The Command Pattern

Encapsulating individual pieces of application logic inside dedicated objects instead of spreading all of that logic through a single controller class.

The Mediator Pattern

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.

Do you need a framework at all?

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:

Table 1-1. The pros and (balancing) cons of using frameworks

Pros	Cons
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

Reasons to use a framework

Consistency

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.

Common understanding brings easier collaboration

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.

Peer-reviewed solutions

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.

A well-tested skeleton

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.

Less code to write

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.)

Reasons not to use a framework

Framework learning curve

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.

Terminology confusion

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”.

Performance tradeoffs

Code that is flexible is rarely as fast in execution as code that is finely tuned to solve one specific problem.

Framework coupling

You may find that you’re unable to reuse your code in projects which don’t use the same framework.

‘Black box’ code is hard to debug

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.

Robotlegs aims to amp up the pros and minimize the cons

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.

Less boilerplate code is a good thing...

...but Robotlegs is not just about less code

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.