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

[@kranid]

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

[@ynlvko]

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

[@kozhevnikovv]

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

[@ynlvko]

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

[@iLLuzor]

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

[@agent10]

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

[@WelloGraphics]

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

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

[@agent10]

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

[@iLLuzor]

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

[@Maksclub]

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

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

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

[@agent10]

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

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

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

[@Maksclub]

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

[@a_artikov]

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

[@Dev_Nikolya]

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