Ладонь против Ножа: Ручной DI вместо Dagger

Но что делать, если моя кофемашина сама имеет какую-то зависимость? Например, некоторый CoffeeConfig? Я могу заставить того, кому нужна зависимость, предоставить нам его. В терминах Dagger это называется сложным словом AssistedInject. В терминах ручного DI это называется “добавить параметр”.

class Factory {
    fun buildMyCoffeeMachine(config: CoffeeConfig): CoffeeMachine
}

Ладно, конфиг ещё можно как часть API как-то переложить на вызывающего метод. Но если моей кофемашине нужен какой-нибудь WaterSupply, его точно не нужно таскать в каждое место, где требуется кофемашина. Тогда я могу передать WaterSupply в мою фабрику.

class Factory(val supply: WaterSupply) {
    fun buildMyCoffeeMachine(config: CoffeeConfig): CoffeeMachine
}

Теперь давай представим что этот WaterSupply собирается в свою очередь какой-то другой фабрикой. Как мне соединить две фабрики между собой и не помереть под горами бойлерплейта?

class WaterFactory {
    fun buildWaterSupply(): WaterSupply
}
class CoffeeFactory(val supply: WaterSupply) {
    fun buildMyCoffeeMachine(config: CoffeeConfig): CoffeeMachine
}

Обычно здесь авторам статей про DI надоедать играть с фабриками и они начинают расчехлять свой DI фреймворк. Пример же с фабриками расценивается больше как пузырьковая сортировка при изучении алгоритмов - просто, понятно, но в продакшне не используется. Но достаточно всего лишь знать одну фичу Kotlin и бойлерплейт уходит сам собой

Пока код я только добавлял, хотя глава называется “убираем бойлерплейт”. Но на самом деле я его перепрячу “под ковёр”. До этого я не показывал конструктор CoffeeMachine. А там вот что!

class CoffeeMachine(val config: CoffeeConfig, val deps: Dependencies) {
    interface Dependencies {
        val waterSupply: WaterSupply
    }
}

Ха-ха, вот это я тебя подколол, да? Отрефакторил код, ещё до того как показал его сниппет. Но теперь, когда карты на столе, маски сняты, и я застал тебя врасплох, позволь показать тебе ещё один трюк с рефакторингом “задним числом”. Взгляни ещё раз на фабрику кофемашин.

class CoffeeFactory(
    val deps: Dependencies
): CoffeeMachine.Dependencies,
   Dependencies by deps {
    fun buildMyCoffeeMachine(config: CoffeeConfig): CoffeeMachine =
        CoffeeMachine(config, this)
    interface Dependencies {
        val waterSupply: WaterSupply
    }
}

Ха, теперь я могу просто передавать this в качестве зависимостей и всё работает! А благодаря трюку с by делегацией описывать зависимости, которые я взял из внешнего скоупа - не нужно, они уже подходят под интерфейс.

Так как Dagger завязан на типы возвращаемого значения, чтобы разделить две зависимости одного типа, ему пришлось вводить Named. А теперь, следите за руками:

interface Dependencies {
    val waterSupplyA: WaterSupply
    val waterSupplyB: WaterSupply
}

Вау, две зависимости одного типа, без аннотаций, как мне это удаётся?

Помню как в своё время очень долго пытался разобраться, что же делают скоупы в Dagger. А вот что они делают в ручном DI:

class MyFactory: MyDependencies {
    // No scope
    override val dependencyA get() = DependencyA()
    // Scoped to MyFactory
    override val dependencyB = DependencyB()
}

Закрыть скоуп можно, просто потеряв ссылку на MyFactory, не благодари.

Если какая-то зависимость нужна не прям щас, а как-нибудь потом, то из предыдущего примера не сложно догадаться, что это легко решает by lazy.

class MyFactory: MyDependencies {
    override val someLazyDep by lazy { SomeLazyDep() }
}