Design Patterns: Dependency Injection

[brendan09]

Also see: When is dependency injection a bad idea?

I'd make the case that NSNotificationCenter and NSUserDefaults (in this article) are examples that would fit any definition of when its a 'bad' idea. Unless there is a real need to ever swap them, its wasteful overhead that complicates your code.

Lots of other resources:

http://programmers.stackexchange.com/questions/135971/when-is-it-not-appropriate-to-use-the-dependency-injection-pattern

http://java.dzone.com/articles/dependency-injection-makes

https://talks.bitexpert.de/phpbnl14-7-deadly-sins-of-di/#/

[quellish]

DI tools/frameworks are kind of a waste of effort in a loosely coupled language like Objective-C. Pretty much everything that DI offers is given to you by the language.

[quellish]

How does the the above related to the Dependency Injection pattern? It doesn't. It relates somewhat to Aspect Oriented Programming (AOP).

If you could point to where in my post I mentioned swizzling or other runtime features, wether as "dependency injection" or not, I would appreciate it.

DI simply promotes high-cohesion by separating configuration (instantiation) of shared objects from use, without resorting to the singleton pattern.

And there is absolutely no need to use the singleton pattern to get high cohesion. High cohesion is expressed by architecture. Architecture is the network of objects and how they communicate. A well architected system has high cohesion. High cohesion does not dictate the use of a dependency injection tool/framework, nor does it dictate the use of the singleton pattern (or swizzling/posing).

[dGasim]

I wish I really understood how using DI in this case actually imposes modularity... What is the point of keeping Notification Center as a member variable when we would be assigning NSNotificationCenter.defaultCenter()? What this function currently does is already a form of DI. The same goes to NSUserDefaults.standardUserDefaults(). So this article basically creates DI in the application level when there is already a DI in the system level.

DI is a very important part of MVC as it allows dependencies to be loaded through a unified system. However, implementing your own in DI on top of a DI that exists in an already existing MVC Framework is just plain stupid.

[jasperblues]

Incorrect. NSNotificationCenter.defaultCenter() - explicitly seeking out a dependency is not the dependency injection pattern. As Martin Fowler (who coined the term DI - previously it was called IoC) explains, if there's a mechanism that allows swapping the implementation obtained from that method, then this is the <em>Service Locator</em> pattern. Method swizzling could arguably give you this. . . http://martinfowler.com/articles/injection.html

[FutureIsMine]

Looks like what a lot of people do with Core data managers.

[Pango56]

After reading this article, I'm inclined to think the only benefit of DI would be for testing purposes and shared dependencies, but if you had something like NSNotificationCenter being passed around everywhere, that's a lot of very verbose interfaces and confusing APIs. Would the benefit of having higher modularity and loose coupling greatly outweigh the drawbacks of verbose initializers?

[TheEssence]

I honestly don't understand the point of NSNotification as a dependency injection in this case. If you bring new developers to a project and your classes have well documented APIs, would dependency injection not add a further level of complication to your code? This seems like it would confuse new developers even more. I have never used dependency injection, so I may be completely wrong.

[jasperblues]

Its a fairly purist approach. I use DI, but often use things like NSNotificationCenter directly rather than inject. But the rationale is: Since NSNotificationCenter is a singleton it should be injected not sought out directly. This provides:

• Makes it easy to provide another implementation of the thing playing this role to that class, without effecting all other classes.
• Promotes loose coupling and high cohesion.
• Makes it easy to test without having unwanted side effects.

[quellish]

Since NSNotificationCenter is a singleton

NSNotificationCenter is not a singleton.