A new Swift video series exploring functional programming and more.
#18 • Monday Jun 4, 2018 • Subscriber-only

Dependency Injection Made Comfortable

Let’s have some fun with the “environment” form of dependency injection we previously explored. We’re going to extract out a few more dependencies, strengthen our mocks, and use our Overture library to make manipulating the environment friendlier.

This episode builds on concepts introduced previously:

#18 • Monday Jun 4, 2018 • Subscriber-only

Dependency Injection Made Comfortable

Let’s have some fun with the “environment” form of dependency injection we previously explored. We’re going to extract out a few more dependencies, strengthen our mocks, and use our Overture library to make manipulating the environment friendlier.

This episode builds on concepts introduced previously:


Subscribe to Point‑Free

This episode is for subscribers only. To access it, and all past and future episodes, become a subscriber today!

See subscription optionsorLog in

Sign up for our weekly newsletter to be notified of new episodes, and unlock access to any subscriber-only episode of your choosing!

Sign up for free episode

Introduction

A few episodes ago we covered dependency injection. We saw that dependencies are things that “speak” to the outside world and because of this are full of side effects, which makes our applications complex. We covered the most popular way of handling dependencies in Swift, which is to put a protocol in front of it, explicitly inject it into initializers of objects that want those dependencies, and then you’re free to plug in a mock version that serves mock data.

We found that this approach has a pretty big problem. It adds a lot of boilerplate. Every dependency added required at least five or six places that needed to be updated, including mocks, initializers, call sites, etc. We proposed a solution that might make some folks feel a little uncomfortable: to reign in all those global singletons and pack them into one single singleton that we called the “current environment”. We saw that this approach cleaned up that boilerplate we saw with the protocol-based approach: new dependencies required very few changes. This approach is also very simple and could be introduced to a code base easily, today, without many changes!

Still, we know how strange this approach can seem at first glance, and we don’t want people to be uncomfortable with it. We want people to see just how simple it is. We’ve used it in our code bases many times.

This episode is just going to be about getting comfortable with it. Let’s relax, step through the app we were building last time, extract out a few more dependencies, and explore how setters can help us.

Subscribe to Point-Free

👋 Hey there! Does this episode sound interesting? Well, then you may want to subscribe so that you get access to this episodes and more!


References

Chapters
Introduction
00:05
Recap
02:02
A simple mock
06:47
Mocking made easy
08:54
Refactoring made easy
12:51
More hidden dependencies?
14:39
Another hidden dependency?
21:45
What’s the point?
27:31