Why use the SwiftSuspenders?

[gilamran]

Hi,
I'm quite new to the Injection thing, but I can say that I've read
allot about it...

I'm still puzzled about why use the SwiftSuspenders package to do your
injections?
I know that IOC is important, and it's a good practice... but using
injection with metatags...
Isn't it easier just to call a setter function?

Thanks
Gil

[Stray]

Hi Gil,

I'm afraid it's a bit of a case of 'suck it and see' (as we say in the UK).

There are a bunch of theoretical arguments, but you don't really appreciate the value of the SS/RL approach until you've worked through a project, with all the usual headaches, and found that on many occasions the SS/RL package makes your life easier.

'Just call a setter function' - is an interesting use of the word 'just'...

Hopefully you'll give it a whirl and realise how many things 'just work'. Another interesting use of the word 'just' ;)

> --
> You received this message because you are subscribed to the Google
> Groups "Robotlegs" group.
> To post to this group, send email to robo...@googlegroups.com
> To unsubscribe from this group, send email to
> robotlegs+...@googlegroups.com
> for support visit http://knowledge.robotlegs.org

[Jesse Warden]

Gil, I'm not much of a fan, and still suspicious as well.  However, if you come from PureMVC, you go from this:

private var proxy:MyProxy;



var proxy:MyProxy = facade.retreiveProxy(MyProxy.NAME) as MyProxy;
trace(proxy.myVO);

To this:

[Inject]


public var model:MyModel

;

trace(model.myVO);

Effectively, solving 2 things:

1. less typing

2. solves race conditions (did I already initialize my Proxy/Model yet?)

There are other benefits, but those 2 are good enough for me.

[gilamran]

Guys, you start to convince me...
keep going... I'm almost there :-)

On Jun 28, 12:00 am, Jesse Warden <jesse.war...@gmail.com> wrote:
> Gil, I'm not much of a fan, and still suspicious as well.  However, if you
> come from PureMVC, you go from this:
>
> private var proxy:MyProxy;
> 

var proxy:MyProxy = facade.retreiveProxy(MyProxy.NAME) as
> MyProxy;
trace(proxy.myVO);
>
> To this:
>
> [Inject]
> public var model:MyModel

;
>
> trace(model.myVO);
>
> Effectively, solving 2 things:
>
> 1. less typing
> 2. solves race conditions (did I already initialize my Proxy/Model yet?)
>
> There are other benefits, but those 2 are good enough for me.
>

> > > robotlegs+...@googlegroups.com<robotlegs%2Bunsu...@googlegroups.com>
> > > for support visithttp://knowledge.robotlegs.org

>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Robotlegs" group.
> > To post to this group, send email to robo...@googlegroups.com
> > To unsubscribe from this group, send email to

> > robotlegs+...@googlegroups.com<robotlegs%2Bunsu...@googlegroups.com>
> > for support visithttp://knowledge.robotlegs.org

[Jesse Warden]

Another is you have some flexibility with injection rules.  There are too many to cite, but here's a couple.

Most Models are singletons for whatever reason.  Say you only ever have 1 User logged into your application, thus, you make the User Model a Singleton as well.  However, you don't have to make it a Singleton.  You can simple map it as such:

injector.mapSingleton(UserModel)

That way, you can still instantiate the class with multiple instances if you want to test something, or use it elsewhere.  Additionally, if you change your mind later, you can just update the injector to map it as an instance instead.  It's subtle, and an edge use case to me, but certainly a nice to have in the beginning of projects where you are figuring out your data model, or you're waiting on the server guys to tell you what the bloody hell it actually is.

Another one is injecting interfaces.  Now, I'm only a fan of Interfaces in API's.  It makes sure that developers aren't locked into your class structure, and your API is flexible enough for their needs, yet ensures you can actually support it without breaking future changes since the interface ensures (for the most part *ahem*) implemented behavior doesn't' change.

Eventually, though, SOMEONE has to instantiate this interface as a concrete implementation.  This someone will be using a class to do so.  That code, often, is concrete as well; meaning, not configurable.  Using injections, however, it is.  That, and rules to do so are separate from the implementation.  The most common use case for this is when you're working on a project that has a brand new middle tier.  Perhaps, since you're a Flash dev, you're WAYYYY faster than the back-end dudes.  So, you're reading to start using a UserVO in your application... but the server guys don't even have a dev server for you yet.

No problem, you use a MockLoginService instead.  It'll login, and give you a UserVO:

[Inject]

public var loginService:ILoginService;

However, the next day, the devs give you a real service.  Cool, you code a real LoginService to parse the response, and ensure it's a valid response + valid user.  If so, great.

[Inject]

public var loginService:ILoginService;

Noticed nothing changed.  The only thing that changes in the rules in your Context (or whatever you're using to setup your service rules; see Joel's startup manager).

This:

injector.mapClass(ILoginService, MockLoginService);

Would go to this:

injector.mapClass(ILoginService, LoginService);

No matter how many classes utilize ILoginService, nothing for them changes.  They have no clue whether they are talking to a local XML file, or a real dev server... or a staging server, etc.  This also has benefits for Mock data in unit tests, and others.

Regardless, it's nice to have an easier way to participate in the whole "coding by contract" that Interfaces provide.  Now you can more easily configure what those interfaces actually become.

In conclusion:

- more flexibility with Singletons, specifically for data

- more flexibility when coding by contract via interfaces

[Josh McDonald]

I'm sure you could say I've got a conflict of interest when it comes to DI, but I had to be sold on the concept before I started to implement it :)

It's one of those things that not everybody can see the benefits of without jumping in and using it, and it's going to go away when we get better runtimes for our code (like Newspeak), but when it's done right - and SwiftSuspenders is done right - the extra work is minuscule compared to the benefit you'll get as soon as you have to make a few changes to your app.

I definitely recommend @Dhanji's book on the subject: http://www.manning.com/prasanna/

He's one of those guys that makes you realise how much you don't know :)

(sorry for being so late on the thread, I've been on holiday)

-Josh

--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

Josh 'G-Funk' McDonald
  -  jo...@joshmcdonald.info
  -  http://twitter.com/sophistifunk
  -  http://flex.joshmcdonald.info/

[Jos Yule]

Oh, another book for the wishlist! Thanks for the pointer!

j

On 2010-07-06, at 21:55 , Josh McDonald wrote:
> <cut>

> I definitely recommend @Dhanji's book on the subject: http://www.manning.com/prasanna/
>
> He's one of those guys that makes you realise how much you don't know :)

> </cut>