Moreover they can all perform automatic DI by parsing class metadata. It would be grand if the common DI related metadata tags could be standardised. That way we really could write code that is decoupled from any particular framework.

I’ve started a little document over at GitHub:

http://github.com/darscan/AS3-DI-Metadata

I don’t know the libraries well enough to fill in all the details, so if you could fork the repo and edit the doc that would be great! Also, the format/layout could be better, so if you have any ideas on that front.. edit away.

Actors may be dependent on actors below them in the diagram, but should not be dependent on anything above them.

Commands, Services and Proxies may dispatch system events, but should never listen for them.

Mediators may both dispatch and listen for system events.

So:

1. Commands may depend on any number of Mediators, Services and Proxies, and may dispatch system events.
2. Mediators may depend on other Mediators, Services and or Proxies, and may dispatch and listen for system events.
3. Services may depend on Proxies, and may dispatch system events.
4. Proxies may depend on other Proxies, and may dispatch system events.

Why?

Check out the PureMVC FAQ: http://puremvc.org/content/category/3/23/188/

Prompted By:

This comment, thanks!

UPDATE: I somehow completely messed up the diagram when I last updated it.. I got the direction for the Service and Proxy event flow backwards.. Doh!

Constructor Injection vs Setter Injection
Constructor vs Setter Injection – Constructor is Better
Setter injection versus constructor injection and the use of required

Before I built RobotLegs I was sold on constructor injection. My prototype, however, used SmartyPants-IOC which lacked constructor injection, so I bit my lip and used setter injection. In practice I found that often, especially with framework actors, it was incredibly convenient.

Effort

Unless you use a code generator, constructor injection requires roughly 3 times the effort (more code) and is roughly 3 times more prone to human error than this form of setter injection:

public class SomeMediator

{

  [Inject] public var someView:SomeView;

  [Inject] public var someProxy:SomeProxy;

  [Inject] public var someService:ISomeService;



  public function SomeMediator()

  {

  }

}

Constructor injection requires twice the number of declarations and an extra assignment step.

public class SomeMediator

{

  private var someView:SomeView;

  private var someProxy:SomeProxy;

  private var someService:ISomeService;



  public function SomeMediator( someView:SomeView, someProxy:SomeProxy, someService:ISomeService )

  {

    // Boilerplate...

    this.someView = someView;

    this.someProxy = someProxy;

    this.someService = someService;

  }

}

Forgetfulness

Let’s consider what Misko deems the biggest problem with setter injection: forgetting dependencies.

In the case of setter injection, and in the context of the application itself (running on the RobotLegs framework), if we forget to set up a dependency rule, we’ll get a runtime error when the DI framework tries to inject into the Mediator (which happens automatically). This would be exactly the same for Constructor injection. A draw.

If we are instantiating the Mediator manually (in a unit test for example), and we don’t manually inject into it with our DI framework, then setter injection is obviously weaker – we won’t get the DI RTE, we’ll just get a null-pointer exception at some point in our test. Constructor injection is much better here, but something Misko overlooks is that constructor injection is more prone to human error from the inside. We have at least three places where we can forget to properly take care of our dependencies:

1. We might declare the dependency in our constructor argument list, but then forget to store the passed value inside our constructor.
2. We might declare a property on the class itself but then forget to ask for it in the ctor argument list.
3. We might even be so delirious as to incorrectly assign the values in our ctor by excluding “this.”.

None of those mistakes will cause a compile-time error. As with setter injection, we’ll just get a RTE at some point. Again, a draw.

When we consider what a Mediator is, and the fact that Mediators are amongst the biggest candidates for re-factoring (we might start with one Mediator for a complex nested view, for example, and then break it out into several finely grained Mediators later), setter injection becomes even more convenient. Constructor injection requires more effort when dependencies change: 3 places need editing, including the constructor’s method signature – necessitating external changes for any manually instantiated instances.

Inconsistent State

Another charge against setter injection is that it can be responsible for objects in inconsistent states: directly after construction, and before injection has occurred, the object is not quite ready for use (it’s dependencies are missing). But this isn’t much of a problem when your architectural framework handles that side of things automatically – it instantiates and injects things for you.

Hybrids In Progress, A Sliding Scale

I’d also like to touch on the mixing of injection styles. Some people see this as akin to mixing coding standards in a project – ugly. At the same time, setter injection must be used under certain conditions (circular dependencies for example), so even purists have to mix styles sometimes. I’ve chosen to roll with it, and use what makes the most sense for the case at hand. Looking at actors in the RobotLegs framework, I’m inclined towards:

• Setter injection for Mediators
• Setter injection for Commands
• Constructor injection for Proxies
• Constructor injection for Services
• Constructor injection for non-framework entities

My reasoning is that:

• Mediators and Commands generally have more dependencies and require refactoring more frequently
• Proxies and Services should have very few dependencies
• Non-framework entities are more likely to be created manually

If we look at setter vs ctor injection on a sliding scale, we have:

• setter -> constructor
• convenient -> safe

We can always migrate from setter to ctor injection as classes settle down and their refactoring likelihood decreases:

• setter -> constructor
• sketchy -> final

Mediators, by their very nature, are the sketchiest parts of an application: they are tightly coupled both to the application and the view. Commands are coupled to the application. There is very little need to make either of these actors “safe” or “final”, and for flexibility it is wise to leave them “convenient”.

Proxies and Services, however, should not be too coupled to the application. They should be the “safest” most “final” classes in the interests of loose coupling and portability. I would start with setter injection and migrate to constructor injection as those components mature.

Prompted By:

This comment, thanks!

The State Of The Game

There are some great Flash and Flex application frameworks out there right now. Mate, Swiz and PureMVC (update: and Parsley!) stand out. The authors of these frameworks realized that the Flash Platform is different enough to the JVM to warrant a fresh approach to application design.

Someone mentioned recently that for such a young language (referring to Action Script 3), it’s quite surprising how many frameworks have sprung up around it. I’m not surprised at all: rich internet application development is complicated.. and it’s a pretty recent field in the grand scheme of things. It brings new (and often subtle) twists to traditional web and desktop software development. Writing elegant, maintainable code is hard enough as it is, but doing so on a rapidly evolving, heavily interactive platform.. well, people are still working on the best way to approach that (unless I missed the big news – in which case you can stop reading right here).

Hence all the groovy new architectural frameworks popping up. They share some common goals:

1. Help developers write good, clean, understandable, testable, maintainable code
2. Help them write that code faster
3. Provide an easy-to-use mechanism for application/context/module subsystem inter-communication
4. Provide an easy-to-use mechanism for wiring distinct parts of the application together whilst keeping those parts loosely coupled

And they succeed. To various degrees. I think they’re all pretty cool.

A Poke In The Back With A Sharp Stick

So why build another one?

1. For fun – it’s how I learn stuff
2. Because I find the other frameworks critically flawed

What kind of “critical” flaws?

1. Singletons (big “S”)
2. Central/Static Event Dispatchers
3. Using the Display List as an Application Event Bus
4. Casting
5. The Service/Model Locator Pattern
6. The Presenter Pattern
7. Injecting into View Components

And what’s wrong with those things?

They are bad ideas:

1. The Singleton – Bad Idea

The standard Singleton implementation (that static getInstance method) is severely flawed. Unless you are writing device drivers, there is almost no excuse to touch a Singleton with a sharp stick.

Singletons bring bags of hurt to frameworks and applications.. suddenly, trying to build a modular application becomes an overly complicated affair, and unit testing becomes a nightmare. Singletons are viruses – they infect every class they touch.

And Multitons? If Singletons are evil, Multitons are diabolically evil. What makes the Multiton pattern incredible is that it manages to chump the Singleton as the worst Design Pattern Of All Time – no easy feat, and certainly the work of an evil genius with a wicked sense of humour. Not only do we have all the problems of the classic Singleton, we throw a poorly designed Model Locator into the mix – to pull out these horrendous Singletons we now need to use String keys.

Contextual singletons (as made possible by Dependency Injection frameworks) are a much nicer solution, they don’t require any extra (fluffy, nonsense, ill placed) code on the target classes themselves, and they allow identical applications/modules to exist side-by-side in the Virtual Machine without fighting and mass confusion. Which leads me to..

2. Central/Static Event Dispatchers – Bad Idea

As convenient as it is to use, a Central Dispatcher is a really bad idea. Another Singleton effectively. Pop two apps into the same SWF and watch, with excitement and glee, all the cross-talk that occurs – both apps responding to each other’s events. Oh noes!

Architectural frameworks generally provide you with an application event bus/channel/dispatcher to “chat” on, but this should be localised to the application itself (or some other context). Which leads me to…

3. Using the Display List as an Application Event Bus – Bad Idea

I find this one fairly disturbing too: dispatching system/application events along the display list. No!

A View is just that: “A view”, not “The view”. And don’t get me started on those innocent looking Event Maps! No, let’s move along…

4. Casting – Bad Idea

Besides wasting space and annoying programmers, casting distributes knowledge throughout a system – casting requires that you look elsewhere in your codebase for the “real” type.

And it weakens our lovely compile-time type checking (albeit temporarily), sending us back in time to our unhappy days building complex applications in the Flash IDE. And it’s boring. And it often occurs because of..

5. The Service/Model Locator Pattern – Bad Idea

Classes should not be responsible for “fetching” their dependencies – this is a separate responsibility that belongs somewhere else entirely – they should only contain code for doing their job. When classes reach outside to fetch things from the application/context they sneakily hide their dependencies away from the outside world.

Unit testers will despise you (which is a serious problem if you are writing your own tests) because it becomes incredibly hard to figure out how much set up needs to be done to write even the smallest of tests. You have to look inside the class for any calls to the Service Locator to find your direct dependencies, and then you have to look inside each of those classes to find theirs and so on. No no, that’s just cruel.

6. The Presenter Pattern – Bad Idea

Ok, it’s going to be tricky to back this one up. But think about it this way: the Presenter pattern requires that you modify your View component (to add a reference to a Presenter). Not a biggie, but once you’ve done that you’ve started coupling your View component to your application/context – a slippery slope.

I think the Mediator pattern is a much better fit for Flash and it’s Display List, and even more-so when it comes to Flex (and other UI frameworks with complex component life cycles).

It is far easier and cleaner to “wrap” around view components and poke their APIs than to have to modify (extend) them to make space for their Presenter references. Leave those components alone, leave them to the component developers, you’re supposed to be writing an application. While we’re on the Presenter pattern, let’s take a look at something dirty one might do in an attempt to salvage it’s reputation..

7. Injecting into View Components – Bad Idea

Besides being incredibly slow and wasteful (especially for Flex UIComponents), injecting directly into a View component couples it to your application/context.

View components, with any hope for reuse, should be as self-contained as possible. They should expose an API and dispatch Events. They shouldn’t be dependent on the application they are in or the framework it happens to be using. Give ‘em ViewModels (M-V-VM) if you must, but don’t go and couple those ViewModels to your application, and certainly don’t inject them.

Wrapping Up This Micro-Post

Well that’s just your opinion, dude

Yeh, but I’m pretty proud of my little 7 point list there (cos I’m an OOP noob, and this stuff gets me amped). Using Dependency Injection I was able to avoid all those nasty things when building my own PureMVC-like framework.

But that just shifts the problem somewhere else

Yes, somewhere more appropriate.

Besides some convenient implementations (in the mvcs package), and some marker interfaces (in the core package) RobotLegs essentially provides two things:

1. A Command Factory – for binding Commands to Events, and
2. A Mediator Factory – for handling automatic Mediator creation and registration

Everything else is handled by a Dependency Injection framework and an Event Dispatcher.

Note: If you’ve been through all this before, I apologise, it’s new to me.. I’m a little slow.

Beware: the current default implementation of RobotLegs makes use of annotated setter injection. This breaks encapsulation, is open to misuse, and runs the risk of leaving objects in partially initialised states, but it’s very convenient! You can swap out SmartyPants-IOC for a Dependency Injection framework that performs constructor injection if you really want to play it safe.

I’ll admit straight-up (albeit as a footnote) that I never really gave Cairngorm much of a chance – preliminary research led me to demos, documentation and diagrams that screamed poor design and foreshadowed immense struggle. I’m sure there is a way to build a well designed Cairngorm application, but it looks like it’d take an awful amount of effort.. and code. And it probably wouldn’t be very much fun.

UPDATE: Removed some words that made me sound like a douche bag.

RobotLegs AS3 v0.2 (codename ReversiblePants) is up on GitHub:

Now with DI/IOC and Reflection adapters instead of direct dependencies on the SmartyPants-IOC framework. By providing your own adapters you can run RobotLegs off a DI/IOC/Reflection framework of your choosing.

More info (and updated demo):

http://shaun.boyblack.co.za/blog/2009/04/16/robotlegs-an-as3-mvcs-framework-for-flash-and-flex-applications-inspired-by-puremvc/

I should point out that RobotLegs AS3 is still very much a proof-of-concept framework. It works, but it’s architectural design might change a bit on the road to v1.0. That said, I’m using it underneath a large-scale, real-world project, and it’s working great!

Well, you might enjoy RobotLegs AS3: yet another lightweight micro-architecture for Rich Internet Applications.

It’s got the bits that I like about PureMVC (Mediators, Commands and Proxies) without any of the bits that I’m not so fond of (Service Locator, Singletons, casting casting casting!).

I’ve put the source up on GitHub, so feel free to Fork it and make it better:

http://github.com/robotlegs/robotlegs-framework

Discussion Group:

http://groups.google.com/group/robotlegs

Here’s a little demo:
(Please note: the API and usage has cleaned up a lot since this demo was built)

You can also view the demo here (with view source).

The demo app is perhaps not so great, but it demonstrates many of the framework’s features. AND, there isn’t a single cast in there! No actor casting, no payload casting, not any casting, not even for fun!

I have much to say about this little framework, but it’s the wrong side of 5am and I’ve had a crazy long day. In the meantime, you can find some background info here and here if you’re interested.

Update: RobotLegs Lives!

http://code.google.com/p/smartypants-ioc/

I guess that means that it’s time for me to release RobotLegs – an MVCS micro-architecture for Rich Internet Applications inspired by PureMVC, Mate and Swiz! But first, I have to write a little demo application for it.. coming soon!