views:

2685

answers:

9

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.

+3  A: 

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.

Jason Coco
But what about dependency injection for objects that are not the nib owner? I can instantiate them in the nib and thus use IB for dependency injection, but that's not a very scalable solution (the nib file quickly becomes unwieldy)
Barry Wark
You say "The Nib File", as if there was only one. You can have as many nib files as you like, which is not unwieldy at all.A nib doesn't even have to have an owner, you can put whatever objects you like in a NIB with no owner and pluck them out manually after you load the NIB file.
Kendall Helmstetter Gelner
I think I side-tracked the discussion a bit by mentioning IB. I'm looking for something along the lines of Spring or Groovy.
Barry Wark
A: 

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.

Rolf
No, in fact, I am looking for a DI library.
Barry Wark
+3  A: 

There is no such framework available (yet). Sorry.

tcurdt
+8  A: 

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.

Otto
I think it's telling that Brad Cox, the designer of Objective-C, has spent his life working on loose coupling and software reuse. The dynamic features of Objective-C are there to solve the problems DI solves for static languages. http://ieeexplore.ieee.org/iel2/190/267/00004852.pdf?arnumber=4852
Paul
It's also telling that this Stack Overflow post is now the top Google result for "dependency injection objective-c" and "dependency injection cocoa".
Otto
Categories are great - but I personally don't see how they get you around DI. Modifying an existing class is not the same as changing a full implementation.
tcurdt
Better response, post caffeine - I was more trying to point toward the idioms to hopefully be more helpful than "nope you don't need to do that" without any kind of pointer to something that might help solve the need.
Otto
After re-reading Brad Cox's paper, I agree... he is a hero. But a system that _allows_ late binding is not the same as DI. I'm tempted to give you the bounty for reopening my eyes to the coolnes of ObjC, but it hasn't fully answered my question in the end.
Barry Wark
...In particular, I'm looking for a framework that helps separate object graph construction from program logic.
Barry Wark
Does Core Data not do what you want? Remember, Obj-C uses duck typing, your view isn't going to care what kind of object it your controller gives it (assuming MVC, natch). I don't think I'm understanding the problem you want to solve. Maybe start a whole 'nother question with a specific example?
Otto
@Otto - your Cocoa API ref has gone stale. Similar is now at: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCategories.html
martin clayton
@martin fixed the link, thanks.
Otto
A: 

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.

http://macdevelopertips.com/objective-c/objective-c-categories.html

groovePupil
A: 

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

Manfred
Interesting idea. The associative references are intended to allow adding effective instance variables from, e.g., class categories without having to resort to ugly hacks. I'm not sure if it would lend itself to being the foundation of a DI system, but it's a very interesting idea.Thanks.
Barry Wark
You maybe might find this interesting, too.I just blogged about Dependency Injection on Objective-C. My first blog. http://swbymabe.wordpress.com/2010/02/20/objective-c-dependency-injection-sort-of/
Manfred
I read your blog post, it looks nice and you obviously put a lot of work into it, but the question I was left with is: why do all that when you can just instantiate the object you need? I think @Otto puts it quite well in his answer. Thanks for the Associative References link, though, I'd not seen this before and I think it may well solve a problem I'm wrestling with.
Elise van Looij
Well. DI is for decoupling direct object dependencies. Using a dependency configuration objects can be wired together at runtime. It also helps a lot in unit testing where you can test objects with dependencies more easily.However the Objective-C runtime offers methods which are not available in languages where DI is much more needed. For example the Objective-C runtime function objc_setClass() (http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html) can at runtime exchange the class of an object. This is not possible in Java.
Manfred
Very interesting feature you link to there: didn't know about that until now. I may be able to revise some pretty crufty code I have using this feature. Has anyone written a nice Objective-C wrapper for these pure C functions yet?
jkp
+1  A: 

At this point there is no DI framework for Objective-C. I started to put together the elements which are needed to implement a DI library. Unfortunately as Objective-c has limited introspection capabilities and no annotations it is hard to find a good solution. What I am looking in to is a Guice like solution because I really don't like using XML to describe all the project.

In the mean while here is a manual DI solution which works great :

http://di-objective-c.blogspot.com/2010/06/diy-di-objective-c.html

Honestly I am starting to think that for the relative small projects on iPhone this it is better than an automatic framework.

+1  A: 

What about dependecy injection implementation at http://github.com/mivasi/Objective-IOC

mivasi
+1  A: 

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.

zoul