DEV Community: Abdullah Althobetey

Stable vs. Volatile Dependencies

Abdullah Althobetey — Wed, 16 Feb 2022 22:51:54 +0000

In previous posts, we described dependency injection, which is a technique to inject an object into another object that needs it. But, should we inject all objects that an object needs? Of course not. We should inject volatile dependencies. We can safely directly depend on stable dependencies. This post is about these two concepts.

Stable Dependencies

Stable dependencies contain deterministic behavior. That is, given input (or no input), it always returns the same result (or does the same side-effect).

For example, say we have a simple cart class that calculates the total of given items:

class Cart {
    private var items = [Item]()

    var total: Int {
        var result = 0
        items.forEach { result += $0.amount }
        return result
    }

    func add(item: Item) {
        items.append(item)
    }
}

The behavior of this class is deterministic. When we add an item with an amount of 1, we will always get 1 as the total. When we add another item also of amount 1, we will always get 2 as the total.

So, if we have, for example, a CartViewController class that wants to use this Cart class, we can safely depend on Cart directly.

class CartViewController: UIViewController {
    let cart = Cart()

    // ...
}

In the book Dependency Injection Principles, Practices, and Patterns by Steven van Deursen and Mark Seemann, they describe this rule for stable dependencies:

In general, DEPENDENCIES can be considered stable by exclusion. They’re stable if they aren’t volatile.

I find this general rule very helpful when deciding if I need to inject a dependency or create it directly. So let's look at how to spot volatile dependencies.

Volatile Dependencies

A volatile dependency, on the other hand, contains a nondeterministic behavior. You give it some input, and you get some output. But If you rerun it with the same input, you might get a different output.

A volatile dependency is volatile because:

It depends on an external world to do its work. It’s known as out-of-process dependencies because it does their work outside of the application process.
do a nondeterministic computation such as computations based on random numbers, date, or time
It’s under development or doesn’t exist yet, so we don’t know the outcome of using it.

Let’s look at an example for each one of them.

Out-of-process dependencies

An out-of-process dependency, as the name suggests, does their work outside of our application process. That is, it depend’s on an external world that is outside of our world (the application world).

The obvious example of such dependencies is the network. When you send a request across the network, your request is processed on some external system, a server, or the cloud (which is another name for a server 😄).

For example, this ProductsViewController class directly depends on a volatile dependency:

class ProductsViewController: UIViewController {
    let session = URLSession.shared

    func fetchProducts() {
        let request = URLRequest(url: URL(string: "https://example.com/api")!)
        session.dataTask(with: request) { data, response, error in
            // ...
        }
    }
}

URLSession is a volatile dependency because it deals with the network, an outside world to our application. You will never certainly know the outcomes of the requests it sends. It may fail from the operating system side (e.g., No connection available), it may reach the server, but the server is down, or the server may respond with an unexpected response.

To decouple our view controller from this uncertainty, we should instead inject URLSession:

class ProductsViewController: UIViewController {
    let session: URLSession

    init(session: URLSession) {
        self.session = session
        super.init(nibName: nil, bundle: nil)
    }

    func fetchProducts() {
        let request = URLRequest(url: URL(string: "https://example.com/api")!)
        session.dataTask(with: request) { data, response, error in
            // ...
        }
    }
}

Now you can inject a URLSession with any configuration you want, not just URLSession.shared. Moreover, you can mock network requests using URLProtocol so that you can control the response coming from URLSession either for development or testing purposes:

let config = URLSessionConfiguration.default
config.protocolClasses = [URLProtocolMock.self]
let session = URLSession(configuration: config)
let productsViewController = ProductsViewController(session: session)

For more about mocking with URLProtocol, see this post.

Nondeterministic computation dependencies

The main problem with dependencies that has nondeterministic computations is that you cannot unit test them. Because every time you run them, they will produce a different result.

As an example, say we need to greet a user and tell them either good morning or good evening based on time:

func great(user: User) -> String {
    let now = Date()
    let components = Calendar.current.dateComponents([.hour], from: now)
    guard let hour = components.hour else { return "Hello \(user.name)!" }
    let isMorning = (0...11).contains(hour)
    let greeting = isMorning ? "Good morning" : "Good evening"
    return greeting + " \(user.name)!"
}

great(user: User(name: "Abdullah"))
// Output will be "Good morning Abdullah!" or "Good evening Abdullah!"

Here is an attempt to test this code:

class GreetingTests: XCTestCase {
    func test_greetUser() {
        let user = User(name: "Abdullah")
        XCTAssertEqual(greet(user: user), "Good morning Abdullah!")
    }
}

The problem with this test is that it will succeed in the morning but fail in the evening. This is because our greet function directly depends on a volatile dependency, which is Date().

So, the solution is to use DI to inject a Date:

func greet(user: User, at date: Date) -> String {
    let components = Calendar.current.dateComponents([.hour], from: date)
    guard let hour = components.hour else { return "Hello \(user.name)!" }
    let isMorning = (0...11).contains(hour)
    let greeting = isMorning ? "Good morning" : "Good evening"
    return greeting + " \(user.name)!"
}

greet(user: User(name: "Abdullah"), at: Date())
// Output will be "Good morning Abdullah!" or "Good evening Abdullah!" based on current time

And here is how we can easily test this new implementation:

class GreetingTests: XCTestCase {
    func test_greetUserAtMorning() {
        let user = User(name: "Abdullah")
        let date = Calendar.current.date(bySettingHour: 9, minute: 0, second: 0, of: Date())!
        XCTAssertEqual(greet(user: user, at: date), "Good morning Abdullah!")
    }

    func test_greetUserAtEvening() {
        let user = User(name: "Abdullah")
        let date = Calendar.current.date(bySettingHour: 16, minute: 0, second: 0, of: Date())!
        XCTAssertEqual(greet(user: user, at: date), "Good evening Abdullah!")
    }
}

Under development dependencies

Let’s say you want to create the user interface of a news application. You didn’t yet implement how to fetch that news, or maybe someone else is working on that. To start implementing the UI, you need at least a stub to fetch some news and drive your UI.

struct News {
    let title: String
    let content: String
}

protocol NewsLoader {
    func fetch(completion: (Result<[News], Error>) -> Void)
}

class StubNewsLoader: NewsLoader {
    func fetch(completion: (Result<[News], Error>) -> Void) {
        completion(.success([
            News(
                title: "Title 1",
                content: "Content 1 ..."
            ),
            News(
                title: "Title 2",
                content: "Content 2 ..."
            ),
            News(
                title: "Title 3",
                content: "Content 3 ..."
            )
        ]))
    }
}

class NewsViewController: UIViewController {
    let newsLoader: NewsLoader

    init(newsLoader: NewsLoader) {
        self.newsLoader = newsLoader
        super.init(nibName: nil, bundle: nil)
    }
}

Once you or someone else is done implementing the real news fetching, you can inject the actual implementation instead of the stub.

class APINewsLoader: NewsLoader {
    let session: URLSession

    init(session: URLSession) {
        self.session = session
    }

    func fetch(completion: (Result<[News], Error>) -> Void) {
        session.dataTask(with: request) { data, response, error in
            // ...
        }
    }
}

// Somewhere in your application
let apiNewsLoader = APINewsLoader(session: .shared)
let newsViewController = NewsViewController(newsLoader: apiNewsLoader)

Stable Dependency That Depends on Volatile Dependency

So we described that volatile dependencies should be injected and not directly created. On the other hand, we can safely depend on stable dependencies.

But can we depend on a stable dependency that has a volatile dependency? Let’s see if we do.

Let’s say we want to create a view model for our news example. The view model will handle the fetching of news, so we will inject a NewsLoader in the view model instead of the view controller.

class NewsViewModel {
    @Published var allNews = [News]()
    @Published var loadingError: Error? = nil
    let newsLoader: NewsLoader

    init(newsLoader: NewsLoader) {
        self.newsLoader = newsLoader
    }

    func load() {
        newsLoader.fetch { [weak self] result in
            switch result {
            case .success(let loadedNews):
                self?.allNews = loadedNews
            case .failure(let error):
                self?.loadingError = error
            }
        }
    }
}

The NewsViewModel depends on NewsLoader, which is a volatile dependency, so we inject it. In NewsViewController, we cannot create NewsViewModel directly because it requires a NewsLoader.

One solution is to inject a NewsLoader into NewsViewController, and then the NewsViewController passes the NewsLoader to the NewsViewModel.

class NewsViewController: UIViewController {
    let newsViewModel: NewsViewModel

    init(newsLoader: NewsLoader) {
        self.newsViewModel = NewsViewModel(newsLoader: newsLoader)
        super.init(nibName: nil, bundle: nil)
    }

    // ...
}

As you can see, we only pass NewsLoader to NewsViewController so that we can create a NewsViewModel. This is similar to the middle-man anti-pattern.

Indeed the NewsViewController needs a NewsViewModel, but it doesn’t have to create it.

A better solution is to inject the NewsViewModel into the NewsViewController directly.

class NewsViewController: UIViewController {
    let newsViewModel: NewsViewModel

    init(newsViewModel: NewsViewModel) {
        self.newsViewModel = newsViewModel
        super.init(nibName: nil, bundle: nil)
    }

    // ...
}

Somewhere in your application, you create the NewsViewController like the following:

let apiNewsLoader = APINewsLoader(session: .shared)
let newsViewModel = NewsViewModel(newsLoader: apiNewsLoader)
let newsViewController = NewsViewController(newsViewModel: newsViewModel)

By the way, the NewsViewModel should be considered as a volatile dependency, not a stable dependency that depends on a volatile one.

Once a type depends on a volatile dependency, it itself also becomes volatile. I included this section because it’s a common mistake.

Injecting stable dependencies to pass data

The last thing I want to touch upon is that you might use DI to inject stable dependencies just to pass data.

For example, let’s say we want to display each news on it’s own screen.

class NewsDetailViewController: UIViewController {
    let news: News

    init(news: News) {
        self.news = news
        super.init(nibName: nil, bundle: nil)
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        display(news)
    }

    private func display(_ news: News) {
        // ...
    }
}

The news struct is pretty stable, it’s just two fields of type String, but we don’t know at compile time which News to pass.

At run time, when, for example, we tap on a news in NewsViewController, the news will be passed to NewsDetailViewController.

class NewsViewController: UIViewController {
    let newsViewModel: NewsViewModel

    init(newsViewModel: NewsViewModel) {
        self.newsViewModel = newsViewModel
        super.init(nibName: nil, bundle: nil)
    }

    func tappedOn(news: News) {
        let newsDetailViewController = NewsDetailViewController(news: news)
        show(newsDetailViewController, sender: nil)
    }
}

Conclusion

We looked at the difference between stable and volatile dependencies and that we should always inject the volatile ones. Because volatile dependencies are hard to control, you will lose control of your application if you always create your volatile dependencies directly. If you inject them instead, you will have absolute control over these difficult dependencies.

If each type keeps asking the layer before it for its dependencies, you will find yourself creating all of your dependencies at the root (entry point) of your application, and that is a good thing.

The next post will be about the composition root pattern, a way to create and control all your app dependencies and extend or intercept them.

Dependency Injection Patterns

Abdullah Althobetey — Wed, 16 Feb 2022 22:47:05 +0000

In this post, I will explain dependency injection patterns with examples written in Swift.

Dependency injection (DI for short) is a software engineering technique where an object, method, or function receives other objects or functions that it needs.

Unfortunately, many developers often overlook DI (I certainly did in the past) despite their incredible benefits, especially when your project grows.

Why dependency injection

For me, the most significant benefit of DI is control. With proper DI, you will have more control over your program. Without DI, and as your program grows, your program will probably control you more. We've all been there; think of that legacy library or framework you couldn't replace because it's used all over the place.

For more about DI benefits, see my previous post. For now, let's focus on DI patterns in Swift.

Initializer injection

Initializer injections is the act of defining the required dependencies as parameters to the type's initializer. It can be applied to a class, struct, or enum, and the dependencies can be other classes, structs, enums, or functions.

For example:

class Profile {
    private let user: User

    init(user: User) {
        self.user = user
    }
}

Initializer injection is the most important pattern in DI, and it should be your go-to pattern unless required (see other patterns below).

In the code example above, it doesn't make sense for a Profile to exists without a User, so if you want to use the Profile class, you have to supply a User when you create it.

This will save your code from optionals mayhem. If we define user as an optional inside Profile, we will have a lot of if lets or guards in all over the place in the Profile class.

Method/function injection

Like initializer injection, in method/function injection, you supply the required dependencies as parameters to the method or function.

The reason to use method/function injection instead of initializer injection is that the required dependencies may vary with each method/function call.

For example, let's say in Profile, we can redeem some kind of coupon for user, and the user can redeem any number of coupons. So the dependency (coupon) can vary at each call to the redeem service:

class Profile {
    private let user: User
    private let couponRedemption: CouponRedemption

    init(user: User, couponRedemption: CouponRedemption) {
        self.user = user
        self.couponRedemption = couponRedemption
    }

    func redeem(coupon: Coupon) {
        couponRedemption.redeem(coupon)
    }
}

To do the actual redemption, we need to call some sort of a service object. In this case, it's CouponRedemption, which is another excellent example of initializer injection!

Property injection

Property injection can be applied when a type exposes a writeable property so that callers can replace the property value with another one.

Property injection is often used when a type has a good default dependency. But beware that the default dependency should be what it's often called a stable dependency and not a volatile one. If the dependency is volatile, you should use the initializer injection instead. I'll save the explanation about stable dependency versus volatile dependency in another post.

Another thing to be aware of is the default dependency should originate from the same module or layer. Because if you use a dependency from another module, you will unnecessarily couple the two modules together. In that case, initializer injection is the way to go. Again I will hopefully write about this in another post. For now, let's focus on DI patterns.

As an example of a property injection, let's say in profile, we want the user to select a theme for the application. Of course, we will have a default theme for the app. It's not wise to tell the user to choose a theme the first time they open our app!

enum Theme {
    case darkOrange
    case liteOrange
    case gray
    case blackAndWhite
}

class Profile {
    private let user: User
    private let couponRedemption: CouponRedemption
    var theme: Theme = .darkOrange

    init(user: User, couponRedemption: CouponRedemption) {
        self.user = user
        self.couponRedemption = couponRedemption
    }

    func redeem(coupon: Coupon) {
        couponRedemption.redeem(coupon)
    }
}

Conclusion

As a good tip, always prefer initializer injection unless required. If the dependency your type requires will vary through method/function calls, then use method/function injection. If you have a good default dependency that is stable and originate in the same module or layer, use property injection.

Why Dependency Injection?

Abdullah Althobetey — Wed, 16 Feb 2022 22:40:26 +0000

In the previous post , we discussed the what of DI. In this post, we will explore the why.

DI enables many benefits; before discussing those benefits, let us establish an example. let's say we have a view controller that can display news:

class NewsViewController: UIViewController {
    let newsLoader: NewsLoader

    init(newsLoader: NewsLoader) {
        self.newsLoader = newsLoader
        super.init(nibName: nil, bundle: nil)
    }
}

The NewsViewController uses DI because it doesn't create a NewsLoader. Instead, it states that it needs a NewsLoader.
The NewsLoader is defined as a protocol:

protocol NewsLoader {
    func load(completion: (Result<[News], Error>) -> Void)
}

And we have two types that implement the NewsLoader protocol. One fetches the news from the network. The other fetches the news from a database:

class APINewsLoader: NewsLoader {
    func load(completion: (Result<[News], Error>) -> Void) {
        // load news from the network
    }
}

class DatabaseNewsLoader: NewsLoader {
    func load(completion: (Result<[News], Error>) -> Void) {
        // load news from a local database
    }
}

So you can use the same NewsViewController to display news from different sources. If you want to fetch news from the network, you use:

let apiNewsLoader = APINewsLoader()
let newsViewController = NewsViewController(newsLoader: apiNewsLoader)

If you want to display news from a database, you use:

let databaseNewsLoader = DatabaseNewsLoader()
let newsViewController = NewsViewController(newsLoader: databaseNewsLoader)

With this example established, let's explore the benefits of DI.

Late binding

Late binding basically means that you bind the dependency later. That is, you decide which dependency to use at run time instead of compile time.
For example, say we want to display news from the network only if the device is online. If the device is offline, we will display news from the database instead:

if Network.isOnline {
    let newsViewController = NewsViewController(newsLoader: apiNewsLoader)
} else {
    let newsViewController = NewsViewController(newsLoader: databaseNewsLoader)
}

Dependency Inversion

If our NewsViewController doesn't use DI and creates its news loader dependency directly like so:

class NewsViewController: UIViewController {
    let newsLoader = APINewsLoader()
}

Then we can say our NewsViewController directly depends on APINewsLoader.

However, when NewsViewController doesn't depend on APINewsLoader but depends on NewsLoader. Then in order to make APINewsLoader work with NewsViewController we need to confirm it to the NewsLoader protocol. So we inverted the dependency

Note that instead of the arrow going from NewsViewController to APINewLoader, the arrow goes back from APINewsLoader to NewsLoader, hence the name dependency inversion.

It is worth noting that NewsLoader should be owned by the module (or layer) that owns the NewsViewController. If not, then NewsViewController still has a direct dependency to another module/layer.

If we re-draw the previous diagram between the modules/layers instead of the individual classes, the dependency inversion concept will be more apparent.

So, without using NewsLoader to invert the dependency, we will have a direct dependency between the module that has NewsViewController and the module that has APINewsLoader

If we define NewsLoader inside the same module that has APINewsLoader, then we still have a direct dependency from the first module to the second one.

To invert the dependency, we define NewsLoader inside the same module that has NewsViewController.

Dependency inversion is an essential technique in architecture, where we might want to protect some modules from depending on others. Typically, we want our application code not to depend on frameworks.

In our example, APINewsLoader indeed uses some framework to do the actual networking calls. Since NewsViewController doesn't directly depend on it, we can change or replace that framework without needing to change our UI.

Testability

To unit test the NewsViewController, we want to focus on the NewsViewController behavior itself, and not any collaborating objects. However, we cannot run NewsViewController without a NewsLoader. Since we are using DI to inject NewsLoader, we don't have to inject a real implementation such as APINewsLoader or DatabaseNewsLoader. Instead, we can define a mock implementation of NewsLoader

class MockNewsLoader: NewsLoader {
    func load(completion: (Result<[News], Error>) -> Void) {
        // No need to hit the real network or call the real database
        // you can return any news you want here to use in testing
    }
}

class NewsViewControllerTests: XCTestCase {
    func test_theThingYouWantToTest() {
        let mockNewsLoader = MockNewsLoader()
        let newsViewController = NewsViewController(newsLoader: mockNewsLoader)

        // test code here ...
    }
}

Extensibility

Let's say that you want to load news related to Apple only, and you want to reuse the same NewsViewController to display Apple news.

The two classes we defined above, APINewsLoader and DatabaseNewsLoader, return all news. We don't have to write, for example, APIAppleNewsLoader and AppleDatabaseNewsLoader and implement the same behavior except filtering the news. That is too much unnecessary work.

With proper DI, we can implement this feature without changing existing ones. We can define AppleNewsLoader that implements the same NewsLoader and inject into it another NewsLoader. So we can reuse previous implementations and add on them (extent) new ones.

class AppleNewsLoader: NewsLoader {
    let newsLoader: NewsLoader

    init(newsLoader: NewsLoader) {
        self.newsLoader = newsLoader
    }

    func load(completion: (Result<[News], Error>) -> Void) {
        newsLoader.load { result in
            switch result {
            case .success(let news):
                let appleNews = getAppleNews(from: news)
                completion(.success(appleNews))
            case .failure(let error):
                completion(.failure(error))
            }
        }
    }

    private func getAppleNews(from: [News]) -> [News] {
        // filter and return Apple news ...
    }
}

To use our new AppleNewsLoader with news either from the network or the database, depending on the status of the device network, we can construct our objects as follow:

let newsLoader: NewsLoader = Network.isOnline ? APINewsLoader() : DatabaseNewsLoader()
let appleNewsLoader = AppleNewsLoader(newsLoader: newsLoader)
let newsViewController = NewsViewController(newsLoader: appleNewsLoader)

As you can see, DI enables us to compose and extent our objects in unprecedented ways!

Conclusion

There are many benefits to DI. We only discussed the main ones. These primary benefits also, in turn, enable other benefits. For example, testability enables maintainability, and dependency inversion enables loose-coupling and parallel development.

I will continue to write about DI in my blog, and I'm planning to do a complete sample project. So if you are interested, please subscribe to my newsletter in my website abdullahth.com.

What Is Dependency Injection?

Abdullah Althobetey — Wed, 16 Feb 2022 22:33:39 +0000

Dependency injection (DI for short) at its core is a very simple technique, but using it will enable other advanced patterns and principles that will help you develop clean and loosely-coupled applications.

DI Definitions

Let’s explore some popular definitions of DI.

dependency injection is a technique in which an object receives other objects that it depends on, called dependencies. Wikipedia

In StackOverflow, the popular Q&A website for developers, John Munsch gave an excellent explanation of DI in response to the question “How to explain dependency injection to a 5-year-old?”

When you go and get things out of the refrigerator for yourself, you can cause problems. You might leave the door open, you might get something Mommy or Daddy doesn’t want you to have. You might even be looking for something we don’t even have or which has expired.
What you should be doing is stating a need, “I need something to drink with lunch,” and then we will make sure you have something when you sit down to eat. stackoverflow

Another very compact definition of DI given by James Shore:

Dependency injection means giving an object its instance variables. jamesshore.com

A final definition I will include here is one from the book Dependency Injection Principles, Practices, and Patterns by Steven van Deursen and Mark Seemann. It’s a bit advanced, which states the whole goal of DI:

Dependency Injection is a set of software design principles and patterns that enables you to develop loosely coupled code.

I will write in this blog about many of these principles and patterns. So be around! For now, let’s try to use DI in Swift.

DI in Swift

Here is a basic DI example in Swift:

class Profile {
    private let user: User

    init(user: User) {
        self.user = user
    }
}

The Profile class doesn’t create a user; it states that it needs a user in order to instantiate it. Clients of the Profile class will need to supply the user dependency.

Swift is a general-purpose and multi-paradigm programming language. You can write Swift code in an imperative style (object-oriented programming or procedural programming) or in a declarative style (functional programming).

In Swift, we have classes, structs, enums, methods, and functions. All of these types can receive dependencies which are other classes, structs, enums or functions.

Here is an example of a function that receives a dependency:

func calculate(bill: Bill) -> Int {
    var result = 0
    bill.items.forEach { result += $0.cost }
    return result
}

Another example where a function receives another function as a dependency:

func print(bill: Bill, billCalculator: (Bill) -> Int) {
    bill.items.forEach { print(“\($0.name): \($0.cost)”)}
    let total = billCalculator(bill)
    print(“Total: \(total)”)
}

Conclusion

We only scratch the surface of DI. There are many benefits that DI enables, such as late binding, dependency inversion, extensibility, and testability. We will explore them in the next post.