Комментарии 14
Интересно было бы увидеть как реализуется этот пример с помощью Dagger 2, удивительно, что можно было такого наворотить, что стало его сложно использовать. Сколько не видел IoC-контейнеров, у всех было довольно простое и понятное api.
Когда валидируется граф зависимостей? Если я забыл зарегистрировать Engine, то используя Koin узнаю об этом только в рантайме? Это одна из главных причин почему сервис локатор и
является анти-паттерном.
является анти-паттерном.
Хороший комментарий. У Koin есть возможность провалидировать граф. Но для этого Koin создаёт каждую зависимость, что, с моей точки зрения, является костылём. С другой стороны, это работает и граф валидируется, пусть и не в compile time, а при прогоне соответствующего теста.
Как раз начал попробовать Koin в проекте средне-крупного уровня. Есть несколько вопросов о которых ничего не увидел в документации или пропустил:
1) Хорошо ли проект ложится на много-модульность? Был бы рад увидеть best practice(создавать ли koin модули в каждом градл модуле или норм если всё внутри app модуля)
2) Какие вообще могут встретиться грабли, которые будут трудно решаемы по сравнению с даггером?
1) Хорошо ли проект ложится на много-модульность? Был бы рад увидеть best practice(создавать ли koin модули в каждом градл модуле или норм если всё внутри app модуля)
2) Какие вообще могут встретиться грабли, которые будут трудно решаемы по сравнению с даггером?
То есть вы весь код пропитываете единным интерфейсом сервис-локатора и при переносе некой части кода в другой проект тащите с собой этот интерфейс?
Эти части у вас на неком магическом клее? «Ну вроде должен прислать нужный объект».
Объект всегда можно привести в невалидное состояние — потому для надежности вам просто необходимо свой код покрывать даже не функциональными, а e2e тестами, тк вы должны быть уверенными, что именно в текущей реализации с текущим окружением сервис-локатор притащит вам именно тот самый интерфейс.
Извините, но даже для меня, программиста на динамическом скриптовом языке, это кажется не инженерно и не надежно и дорого по поддержке.
Эти части у вас на неком магическом клее? «Ну вроде должен прислать нужный объект».
Объект всегда можно привести в невалидное состояние — потому для надежности вам просто необходимо свой код покрывать даже не функциональными, а e2e тестами, тк вы должны быть уверенными, что именно в текущей реализации с текущим окружением сервис-локатор притащит вам именно тот самый интерфейс.
Извините, но даже для меня, программиста на динамическом скриптовом языке, это кажется не инженерно и не надежно и дорого по поддержке.
Про какую пропитку интерфейсом речь?
Я нигде у автора в конечно итоговом коде не вижу доп. интерфейсов:
Тоже самое и в Даггере.
Я нигде у автора в конечно итоговом коде не вижу доп. интерфейсов:
interface Engine
class DefaultEngine: Engine
class Car(private val engine: Engine)
Тоже самое и в Даггере.
Dagger 2 тоже можно использовать как service locator, если дергать component откуда ни поподя. Это же относится к любому DI фреймворку. Поэтому не понятно, почему в интернете критикуют именно Koin.
из «из критикантов» можно выделить Jake Wharton twitter.com/jakewharton/status/1142148846065201152
Причем он не гнушается использовать маты в комментариях. Странное поведение. Прям предвзятое.
Причем он не гнушается использовать маты в комментариях. Странное поведение. Прям предвзятое.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Koin – это Dependency Injection или Service Locator?