Dependency Injection Pattern in iOS Development

Dependency Injection Pattern in iOS Development.

In one of the previous articles, I wrote about SOLID — great principles for developing great apps. But what is the Dependency Injection (DI) pattern, and why I mentioned SOLID?

What is the Dependency Injection (DI) pattern?

DI is a pattern that makes a class independent of its dependencies.

Let’s do some code:


Don’t forget about D (dependency inversion) principle from SOLID:


So why is DI important?

The common mistake that every young programmer makes is:


Or even worse:


It means that dependencies of your class rule it. DI pattern prevents it.

FoxMiner shouldn’t care about creating its dependencies. If you remember the first principle of SOLID — Single responsibility. You can interpret this as even creating any other objects inside the class breaking this principle. 

If FoxMiner creates MinerPick on its own, then the programmer can’t check the entire logic of FoxMiner class. The writing test process will be like hell hard. Someone else should create and then inject an instance of MinerPick (not an instance of that particular class, to be exact, but a mock of it).

It is easier to test logic when you can inject dependencies outside of the class:


So you can easily replace all dependencies with mock classes, and writing tests will be a fun process.

Ok, but who will create the necessary instances of classes?

Usually, we rely on the DI framework. Then it is the framework that will responsible for creating class instances.

DI framework

Let me introduce Swinject — a lightweight dependency injection framework for Swift.

For example, we have a bunch of protocols and classes:


and


Swinject is very simple in use. First, we should have a container that will register all our Protocols:

let container = Container()

Now let’s register some protocol and its realization:

container.register(Food.self) { _ in HotDog(name: "hot dog") }

Now when we want to get an object that matches to Food protocol, we call:

let foodObject = container.resolve(Food.self)!

We also can inject inside of registration process:

container.register(Person.self) { r in
    Buyer(pet: r.resolve(Food.self)!)
}

Now in code:

let buyer = container.resolve(Person.self)!
person.eat() // prints "I'm eating hot dog."

Services must be registered to a container before they are used. Services must be registered to a container before they are used. So you can register them in AppDelegate. Also, it is better to use a facade for the Swinject container so you can change the framework for injection whenever you want.

If you don’t want to use a third-party library, then definitely you should check out this library, as your own solution will be like Swinject in the end anyway.

Digital-Only Banking App

What You Should Know Before Building Digital-Only...

What You Should Know Before Building...

What You Should Know Before Building Digital-Only Banking App

Cash is becoming obsolete as the traditional financial system actively adopts modern technologies. Users watch how innovative solutions like Apple...

Android CI/CD boilerplate for publishing via Fastlane

How to Automate CI/CD for Android App with Boilerplate

How to Automate CI/CD for Android App...

How to Automate CI/CD for Android App with Boilerplate

Stop publishing your Android apps manually and start doing this fully automated at any stage.Mobile development, as well as any other software...

Progressive Web App PWA vs. Native App: Which One to Choose.

Progressive Web App PWA vs. Native App: Which One to...

Progressive Web App PWA vs. Native...

Progressive Web App PWA vs. Native App: Which One to Choose?

The current pace of life is not comparable to twenty years ago. And current technologies do not stand still. Every day people are seeking ways to...