Dependency injection framework for Cocoa? [closed]

Question

Interface Builder can be used for basic dependency injection in a Cocoa app, but is anyone aware of more complete dependency injection frameworks for Objective-C/Cocoa for when you don't want to instantiate objects in a NIB file?

Edit

To clarify, I recognize that IB can be used for basic DI, but I'm looking for a framework with more complete functionality, including separate production and testing configurations, along the lines of Groovy or Springs.

Answer 1

What about dependecy injection implementation at Objective-IOC

Answer 2

I’ve written a very simple DI container, the code is on GitHub. It can only do the bare basics, ie. discover the dependencies of an object and satisfy them using other given objects. I have found that to be usable in real-world applications, the code is very simple and it’s fun to hack with.

Answer 3

Has any looked at the Associative References feature of Mac OS X 10.6?

I believe with this it would be possible to build or already have something similar to DI. As far as I have seen however any reference that is needed in an object has to be fetched manually using objc_getAssociatedObject().

Manfred

Answer 4

I think you'll find that you don't need it in late-binding languages like Objective C, Ruby, Lisp and so on. Like Jamis' revelation that he was going down an overly complex path when he tried to build needle, a DI framework for Ruby- Net::SSH revisited.

Here are some links that will hopefully give you some sample code to do similar things in Objective C. With categories you can essentially change any class's behavior at runtime. See Mac Developer Tips – Objective-C: Categories and the Cocoa API docs on categories. Essentially you don't need some central place to ask for "the thing that does x" that is configurable, because you can just instantiate TheThingThatDoesX directly and if something else needs to change/hook into that behavior it can use categories.

Answer 5

Interface Builder does not do ANY dependency injection. It does not need to. Interface Builder serializes objects. When a nib is "awoken" (aka opened), there are no "dependencies" to resolve -- there are just properties to set. Very, very simple. Opening a nib relies solely on the NSCoding protocol and key-value coding.

Dependency injection, pretty much a make-work project at the best of times, or at best a generalized glue layer between components designed independently, is of no use in well written Objective-C code. You are asking for a tool that you don't need.

In Objective-C, software that requires an anonymous service declares a Protocol. Services then adopt this protocol. Clients load services as dynamic plug-ins. On the other hand, if the server was written prior to the client, it is simply a matter of writing a new plug-in which adapts the existing interface to the protocol. This is less work, and more straightforward than trying to define an intermediate data-driven system for "discovering" (please) an interface at runtime.

Is it not obvious to everyone that the big secret of DI is just that it's a way to write code in XML instead of in the native language? I'd really like to hear a good argument as to how XML is somehow a better programming language than a real programming language. It doesn't make any sense.

Answer 6

You don't have to instantiate the object in the NIB file. If you set the File's Owner to your object's class and then link things in the view/window/whatever up to that, you can set your object as the owner at runtime by loading the nib file manually. That way you can have a dynamic instance of an object that still gets dependencies injected properly.