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.

Optimization of Software Delivery Pipeline

Optimization of Software Delivery Pipeline

Optimization of Software Delivery...

Optimization of Software Delivery Pipeline

The development process can be compared with a construction site. While a lot of work is needed to develop databases, applications, etc., a...

Unicorn Companies' Tech Stacks.

Tech Stack of Prominent Companies: What Are Industry...

Tech Stack of Prominent Companies:...

Tech Stack of Prominent Companies: What Are Industry Giants Using to Power Their Applications?

Netflix vs. Hulu, Hubspot vs. Salesforce, Spotify vs. Pandora, Databrick vs. ByteDance, Canva vs. Miro, and Uber vs Lyft are the rivalries that...

Technical Debt in software development.

9. Introduction to Technical Debt

9. Introduction to Technical Debt

9. Introduction to Technical Debt

Software development is a highly volatile industry where new project management tools, frameworks, and methodologies come and go as quickly as we can...