No constructors, If You Please

Quite some time ago there was a lot of discussion about adding interfaces and constructors and a bunch of other Java-esque features to CF. Apart from the great comments by Jared and Sean on the fact that you don’t NEED a constructor as a language construct (the init() convention is fine), I have one more reason to not want constructors – it makes circular resolution of constructor dependencies impossible.

One of the limitations of ColdSpring is that you can’t have constructor injection of circular dependencies. The reason is (presumably) because ColdSpring follows the Init() convention and treats init() as a genuine constructor. If it treated it as a pseudo constructor (which is what it is), there wouldn’t be a problem.

In LightWire, all of the objects are instantiated (without calling the init method) and then the init method is run in each allowing for circular constructor dependencies because of the fact that init() isn’t a true constructor so I can “create” all of the dependent objects and then immediately afterwards can init() them with their dependencies before returning the requested object. Of course, I probably need to do some thinking about making this thread safe for application scoped objects, but it allows for full or lazy loading and for resolution of circular dependencies even in the “constructor” arguments which seems to me to be pretty cool.

So, please don’t add more limitations to ColdFusion. I like it just the way it is!

LightWire: A Little Less Lame

So, I love the concept of LightWire - a lightweight DI engine to provide the basic functionality of ColdSpring for those who prefer programmatic config files or like to put more responsibilities on their business objects and less on the service layer.

I love the fact that I solved the basic problem in under 200 lines of code, but the first cut required you to add two methods to a base class and to tweak your init() methods for all of your objects. It worked as a proof of concept but honestly it was a little lame.

Base classes have their place, but not as a requirement for a DI framework as it makes your application way too knowledgeable about and dependent on the framework, and having to tweak your init() methods completely breaks the benefit of a DI engine that the objects it instantiates don’t need to know anything about it.

So, I’ve fixed these dubious design decisions and I’m liking where it is going.


Why LightWire?

ColdSpring is an amazing and popular DI/IoC framework used by most OO ColdFusion developers. LightWire is a lightweight DI framework that solves a similar set of problems (it doesn't yet have AOP or remote bean creation and provides only a subset of the functionality of ColdSpring).

So, why would you bother looking at LightWire when you already have ColdSpring?

Two reasons: programmatic configuration and Dependency Injection for transient objects.


BlogCFC was created by Raymond Camden. This blog is running version 5.5.006. | Protected by Akismet | Blog with WordPress