ynlvko Feb 12 2020 at 16:48

Koin – это Dependency Injection или Service Locator?

3 min

23K

Programming*Development for Android*Kotlin*

From sandbox

Comments 14

kranid Feb 12 2020 at 17:05

Интересно было бы увидеть как реализуется этот пример с помощью Dagger 2, удивительно, что можно было такого наворотить, что стало его сложно использовать. Сколько не видел IoC-контейнеров, у всех было довольно простое и понятное api.

ynlvko Feb 12 2020 at 19:38

По Вашей просьбе добавил в конец статьи тот же пример на Dagger. Цель статьи не показать, что Koin лучше Dagger'а, а привести пример, что Service Locator можно использовать для Dependency Injection.

kozhevnikovv Feb 12 2020 at 19:38

Когда валидируется граф зависимостей? Если я забыл зарегистрировать Engine, то используя Koin узнаю об этом только в рантайме? Это одна из главных причин почему сервис локатор и
является анти-паттерном.

ynlvko Feb 12 2020 at 20:04

Хороший комментарий. У Koin есть возможность провалидировать граф. Но для этого Koin создаёт каждую зависимость, что, с моей точки зрения, является костылём. С другой стороны, это работает и граф валидируется, пусть и не в compile time, а при прогоне соответствующего теста.

iLLuzor Feb 13 2020 at 20:22

Собственно, так и делается. Пишется специальный тест, который гоняется на ci вместе с остальными тестами и про невалидном графе сборка просто падает.

agent10 Feb 12 2020 at 21:16

Как раз начал попробовать Koin в проекте средне-крупного уровня. Есть несколько вопросов о которых ничего не увидел в документации или пропустил:
1) Хорошо ли проект ложится на много-модульность? Был бы рад увидеть best practice(создавать ли koin модули в каждом градл модуле или норм если всё внутри app модуля)
2) Какие вообще могут встретиться грабли, которые будут трудно решаемы по сравнению с даггером?

WelloGraphics Feb 13 2020 at 12:38

Koin прекрасно дружится с многомодульностью.

Определяете в каждом Android-модуле необходимые koin-модули (публичные). А уже из app достаёте их и указываете при инициализации Koin (startKoin метод).

agent10 Feb 13 2020 at 14:47

А смысл так делать? В даггере можно было так делать скажем для уменьшения нагрузки на apt, а здесь какое преимущество?

iLLuzor Feb 13 2020 at 20:20

Хотя бы прятать реализации за интерфейсами.

Maksclub Feb 12 2020 at 23:15

То есть вы весь код пропитываете единным интерфейсом сервис-локатора и при переносе некой части кода в другой проект тащите с собой этот интерфейс?
Эти части у вас на неком магическом клее? «Ну вроде должен прислать нужный объект».

Объект всегда можно привести в невалидное состояние — потому для надежности вам просто необходимо свой код покрывать даже не функциональными, а e2e тестами, тк вы должны быть уверенными, что именно в текущей реализации с текущим окружением сервис-локатор притащит вам именно тот самый интерфейс.

Извините, но даже для меня, программиста на динамическом скриптовом языке, это кажется не инженерно и не надежно и дорого по поддержке.

-1

agent10 Feb 12 2020 at 23:41

Про какую пропитку интерфейсом речь?
Я нигде у автора в конечно итоговом коде не вижу доп. интерфейсов:

interface Engine
class DefaultEngine: Engine
class Car(private val engine: Engine)

Тоже самое и в Даггере.

Maksclub Feb 13 2020 at 00:52

прошу прощения — прочитал поперек статью и не увидел, что автор оба примера привел. Писал про сервис-локатор

a_artikov Feb 13 2020 at 12:37

Dagger 2 тоже можно использовать как service locator, если дергать component откуда ни поподя. Это же относится к любому DI фреймворку. Поэтому не понятно, почему в интернете критикуют именно Koin.

Dev_Nikolya Feb 13 2020 at 22:36

из «из критикантов» можно выделить Jake Wharton twitter.com/jakewharton/status/1142148846065201152
Причем он не гнушается использовать маты в комментариях. Странное поведение. Прям предвзятое.

Show the best of all time