Tag Archives: design pattern

Loose Coupling through Dependency Injection

https://yalantis.com/blog/dependency-injection-di-service-locator/
http://stackoverflow.com/questions/3058/what-is-inversion-of-control

In case the link does not work, the article can be downloaded and opened from your local machine here

Dependency Injection

Interface Injection

The Problem

follow along with the code in Dependency Injection

Say you have a MovieLister object that has a method moviesDirectedByDirector. It uses a class called TextFileMovieFinder in order to call methods on it and get return values for the results.

This is the simplest solution, but yet, it creates tight-coupling because the method full depends on the exact implementation of TestFileMovieFinder.

Implementing a protocol and using delegate for loose coupling

In the MovieLister, our job is to list. We just need to connect it to a movie finder that gives us the results.

We do this by having a delegate that points to any object that conforms to MovieFinder.
That way, we don’t care what that object does, just give us the result via the protocol MovieFinder’s

..and you use it like so:

Now, let’s update our TextFileMovieFinder object so that it conforms to the MovieFinder protocol.

TextFileMovieFinder.h

TextFileMovieFinder.m

But how do we connect them?

1) Constructor Injection

constructor_injection

Constructor injection is perfect for “obligatory” dependencies, without which the class can’t implement its task. This way we locate all the dependencies in one place – in the constructor. When the class expands and starts using additional services, they will appear in the constructor as parameters which cannot be left unnoticed. So when another parameter is added to the constructor and the number of all the parameters becomes higher than 4, you need to think about the architecture of your class.

2) Setter Injection

setter_injection

Setter injection (property injection) fits “optional” dependencies, those which have a reasonable implementation known to the class by default. At the same time there has to be a possibility to change the dependency while the class is working and without any negative consequences.

Delegates

http://stackoverflow.com/questions/7052926/what-is-the-purpose-of-an-ios-delegate

The advantage of the delegate design pattern is loose coupling. It enables class A (the delegate) to depend on class B (the delegating class) without class B having to have any knowledge of class A. This ensures that the dependency relationship is one-way only, rather than being circular.

It also forms the foundation (lower case “f”) of Apple’s frameworks because it allows them to invoke your code as appropriate when functionality specific to your application is required. For example, responding to a button tap or telling a table view how many sections there should be.