Комментарии 17
спор о том, является ли данный фреймворк реализацией паттерна dependency injection или это реализация service locator
Да сколько можно.
Псевдокодом:
DI:
class Foo {
constructor(Bar bar) {
this.bar = bar;
}
}
SL:
class Foo {
constructor() {
this.bar = SL.get(Bar);
}
}
Transient dependencies, scope итд — это все ортогонально, хотя, конечно, и в юзабельном DI, и в юзабельном SL присутствует.
Любой DI одновременно является SL — ведь всегда есть самый "верхний", явный вызов.
nit:
Самый главный и жирный минус — это то, что мы можем получить ошибку в рантайме, не понимая, откуда она прилетела. Это была проблема первого Dagger, от которой избавились в Dagger 2, перейдя на кодогенерацию при компиляции.
Dagger 1 и был первым продакшн DI, который применил кодогенерацию в компайл тайм. Просто в Dagger 1 часть резолвинга сгенеренного кода делалась через рефлекшн, в Dagger 2 это перенесли на разработчиков и сделали ручной работой, как результат — Dagger 2 не использует рефлексию и сберегает от необходимости конфигурировать proguard/etc, но требует провязки руками.
Kodein очень даже ничего, особенно если вы не сторонник аннотаций прямо в классах и провайда без модулей в Dagger 2, а предпочитаете делать DI более явным. Имхо надо тащить в прод и смотреть как оно приживается, спс за статью
— ты должен знать их
— ты должен их пригласить
— ты должен поить/кормить/ублажать/убирать за ними
Модель Service Locator или «города»:
— связался с сервисом строителей
— ждешь результата
в модели с сервис локатором немаловажное место занимает подтверждение о работоспособности сервиса. Особенностью модели DI — это требование знать специалистов. С возрастанием(разрастанием) проекта (с увеличением кол-ва специалистов) — это становиться все сложней. В модели с сервисами нет явного учета специалистов(хотя он может быть добавлен) — там увеличивается глубина предоставления сервисов, приводящая к их увеличивающейся специализации.
— бумажные
— винил
— флизелин
— стекло
— на российских шпаклевке/клее
— на импортных шпаклевке/клее
В модели с DI ты должен сам найти дядю Васю, который умеет все вышеуказанное
— отслеживать наличие сети
— ранжирование запросов (картинки позднее инфы/контента)
— динамическое регулирование полосы (на 2G — 2 запроса одновременно, WiFi — 8)
— использовать кэширование или без
— группирование запросов — проект со 100 типов запросов это не одно и тоже что 1000 типов запросов
Можно конечно собрать спецов по всему этому и попробовать их объединить. Но уж лучше сразу иметь сервис — просто отправки запросов, который это делает на автомате
В рантайме зависимости, конечно, страшновато — но это смотреть по статистике надо. На 20 млн пользователей её удобно набирать :)
В Кодеине есть какая-нибудь поддержка, аналогичная subcomponent-ам в Даггере? Очень уж удобно с ними ненужные объекты за собой убирать.
Kodein — интересная альтернатива Dagger 2 для внедрения зависимостей в Kotlin