Constructor vs. Setter Injection

Hi Jared,

Firstly I should clarify how I do setter injection (yeah, I know, if I'd published the code already you'd KNOW this!!!).

When you ask LightWire for an object, if it is a singleton, it looks to see if it has already been created (if it is a transient, it skips this step). If so, it just gives you the object. If not, it runs a routine that resolves all dependencies n-levels down (all of the dependencies of the dependencies of the dependencies - unlimited depth) while handling circular dependencies without getting stuck in a loop. It then creates ALL of the objects you need (the objects that your objects need, the objects that those objects need, and so on). It then creates the object you asked for. It then setter injects all of the dependencies into all of the objects you need and into the object you requested. It then gives you the object you asked for.

So, in practice while I am using setter injection, there is a single method call that does everything and the object you get back is fully loaded with dependencies, it is just that the problem is easier to solve this way and it includes the ability to handle circular dependencies which are actually pretty common.

Jared pretty much nailed it but perhaps didn't outline it quite clearly enough:

Constructor injection lets you take existing code that knows nothing about dependency injection or ColdSpring or anything and have ColdSpring (or Lightwire?) use it as-is with no code changes.

Just to reiterate, I have existing code that works like this:

myService = createObject("component","path.to.my.Service").init(some,list,of,args);

At any point, I can take Service.cfc and have it managed by ColdSpring - with no changes to Service.cfc - and reuse it in another piece of code. And we can easily use ColdSpring in our original application too:

myService = application.cs.getBean("myService");

or even just:

function setMyService(svc) { variables.myService = arguments.svc; }

and have CS inject it.

No change to Service.cfc. It doesn't know. It doesn't care.

If you don't have constructor injection, you have to change any CFCs that expect init() to be called immediately on creation.

Should clarify, the whole "create n objects without calling init and then call all of their init methods) is an atomic transaction - you don't have the uninit'd objects floating round - LightWire does all of this in one go and then returns the fully loaded object requested.

Obviously some potential thread safety issues I'll need to think through as atomic NEQ instantaneous!

I may still be missing the point, so help me with this.

I want to get ProductService. ProductService depends on ProductDAO and UserService. UserService depends on ProductService and UserDAO. ProductDAO and UserDAO have no dependencies and we're lazy loading.

I create ProductService (without calling init, so it is unitialized - tacky, but bear with me). I then create all other dependent objects, n-levels down (ProductDAO, UserService and UserDAO) - again without calling their inits.

I then call their inits in any order. For instance, I call ProductService.Init() and give it the reference to the uninitialized UserService and ProductDAO. I then call ProductDAO.init() to initialize it (so now the ProductDAO referenced by ProductService is initialized). I then call UserService.init() passing it a reference to the initialized ProductService and the uninitialized UserDAO. I then call UserDAO.init(), initializing the DAO that was referenced by the UserService.

I do all of this as a "single operation", returning ProductService which is now initialized and fully loaded with initialized objects. Of course, while LightWire was doing all of this I passed in references to objects that hadn't been initialized, but as I wasn't asking those objects to do anything (I was just providing references), who cares?! By the time I returned the ProductService, it and all of its dependent objects were fully initialized, so I get the benefit of resolving circular dependencies AND using "constructor" based injection (clearly it ISN'T constructor based as I'm not using the inits as true constructors - but it LOOKS like constructor based init).

Make sense?

There may well be, but I have it working and it seems to be doing fine - I finally posted the LighrtWire code on RIAForge.com and the whole thing including lazy load, "constructor" injection and resolving circular dependencies for constructor injection in under 200 lines of code so it isn't very hard to check it out or trick it out to work differently.

Who knows, maybe one of my dumb questions will have ended up with an interesting answer?!!!

Yep, that'd fail. I might be willing to live with that as a "cost of doing business" . . .

Just to get an idea, how often do you find yourself calling methods on an injected object as part of your init methods? Is this a theoretical, a seldom but essential, a seldom but could work around or an everyday occurance?

Yep... there ya go.

*sigh*

So much for simple solutions. :) Now that I think of it, I've had this conversation before...

If it really were that simple, it wouldn't have been so hard for the CS folks to take care of the circular references issues they had to deal with.

You know,

On reflection I'm just going to "YAGNI" this for now and leave the engine as it is - just documenting the limitation. I haven't yet come across a use case where I need to call a method on one of the dependent objects within the init method of another.

When/if I do, I'll just have to go back to requiring setter injection for circular dependencies and will have to spend an afternoon getting my head around the constructor dependency resolution order. If nothing else it'll be a cool algorithm to write!

Thanks for ALL the help guys - much appreciated. Between you, you'll make a programmer out of me one of these days :->