Dependency injection framework for Cocoa?

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.

objection by AtomicObject. It is molded in the image of Guice.

I'll go out on a limb and speak on this. Dependency injection as described by the top answer doesn't address the core issue that those seeking to use it are having. We'd like a means of development where component A does not directly instantiate or reference component B. Component A is bound by protocol to component B and is not referenced at all by component A. This allows component B to be replaced at anytime without ever touching component A. I down voted but I will research your references as it seems there are a few who agree with you. I'm not trying to debate, just looking to learn. I'd like to understand more about the "nope you don't need to do that" approach.

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.

Typhoon

Almost one year ago, I released: https://github.com/typhoon-framework/Typhoon

The Typhoon-website lists the key features. A quick summary:

• Non-invasive. No macros or XML required. Uses a powerful Objective-C runtime approach.

• Makes it easy to have multiple configurations of the same base-class or protocol.

• No magic strings - supports IDE refactoring, code-completion and compile-time checking.

• Supports injection of view controllers and storyboard integration.

• Supports both initializer and property injection, plus life-cycle management.

• Powerful memory management features. Provides pre-configured objects, without the memory overhead of singletons.

• Excellent support for circular dependencies.

• Lean. It has a very low footprint, so is appropriate for CPU and memory constrained devices.

• Battle-tested - used in all kinds of Appstore-featured apps

• An internationally distributed core team (we even monitor StackOverflow), so support for any of your questions are never far away :)

API Docs and sample app

• API docs: http://www.typhoonframework.org/docs/latest/api/
• We have a nice sample app: https://github.com/jasperblues/Typhoon-example

Quality Control:

We also maintain a robust quality control system.

• Every commit triggers a series of regression tests

• We maintain high test coverage.

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.

What about dependecy injection implementation at Objective-IOC

What about ObjectivePim? ObjectivePim

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.

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

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.

I work with Spring all day and I've checked Groovy. I'm by no means an XCode/Cocoa expert, but IB does only some dependency injection, which Groovy doesn't even really claims to be doing.

I reckon you are not looking for DI, but rather for a well compiled set of integrated libraries which saves you from typing a lot of code which other people also have typed. I think there are no Spring like frameworks for Cocoa because for some reason people tend to see "Open Source" as "not platform dependant" and therefore Cocoa is a bit left out in the cold.

Depending on your needs though, there are some nice free open source libraries available for Cocoa, all listed on CocoaDev in a nice list.

I know it isn't Spring, but I hope it helps.

DI is a property of a runtime execution enviroment requiring dynamic binding. I'm very new to Obj-C and Cocoa so I may speak out of turn. Unless I'm missing something, I don't see how one could implement DI except by interpreting Obj C rather than compiling it, or by modifying the runtime environment.

I suspect that the DI like behaviour of IB is because there is a domain specific runtime environment associated with apps that are built with it.

I'm happy to be corrected though.

Categories appear to be an implementation of mixin's, allowing dynamic dispatch of methods to a delegate. Rather cool and similar to Java's interface concept, thought the details differ and from the following, I can't see if constants can be defined in a category, though member fields cannot.

objective-c categories