Pull to refresh

Comments 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 — ведь всегда есть самый "верхний", явный вызов.

Это написано не для разжигания споров, а как раз для того, чтобы они утихли. Этот абзац можно было бы пропустить, если бы не было споров о том, DI это или SL. Многие ссылаются на авторитетное мнение стороннего разработчика из гугла, я же предоставил объяснение от создателя библиотеки. Своё личное мнение по данному вопросу я так же высказал, что это все просто поиск смысла в формулировке, а не в том, что делает либа

nit:


Самый главный и жирный минус — это то, что мы можем получить ошибку в рантайме, не понимая, откуда она прилетела. Это была проблема первого Dagger, от которой избавились в Dagger 2, перейдя на кодогенерацию при компиляции.

Dagger 1 и был первым продакшн DI, который применил кодогенерацию в компайл тайм. Просто в Dagger 1 часть резолвинга сгенеренного кода делалась через рефлекшн, в Dagger 2 это перенесли на разработчиков и сделали ручной работой, как результат — Dagger 2 не использует рефлексию и сберегает от необходимости конфигурировать proguard/etc, но требует провязки руками.


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

Пожалуйста! Надеюсь, что он заработает свою нишу и сможет стать библиотекой, которую используют в продакшене на более-менее крупных проектах
Отличная статья, спасибо и главное вовремя)). Переписываю один проект на котлин, как раз думал на чем реализовать ди, пару вечеров уделю данной библиотеке, ну а там как пойдет ). Конечно ошибки в рантайме, это так себе, помню еще их из первого дагера…
Использую Kodein в проекте с самого начала, полёт отличный.
Проблем в рантайме не наблюдается?
Нет, явных проблем не наблюдается, если что-то падает в рантайме из-за Kodein, то обычно моментально выявляется на этапе либо запуска приложения, либо на тестах. В целом впечатления очень положительные.
Готовы ли вы использовать его в энтерпрайз системах, если все пройдет гладко с тестированием? Если да то хотелось бы потом некий фидбэк.
Если мы его внедрим в продакшн и все пройдёт хорошо, то обязательно будет фидбэк
Автор поднимает вопрос разработки сложных (возможно даже динамических) систем. Я предлагаю перейти от модели «деревни» (где каждый знает о соседе все), к вышестоящей модели «города». Где потребитель сервиса ничего не знает о соседе, но может узнать о всех специалистах, который предоставляют сервисы. Модель DI и их аналоги — это модель «деревни». Например — нужно построить дом. В модели DI:
— ты должен знать их
— ты должен их пригласить
— ты должен поить/кормить/ублажать/убирать за ними
Модель Service Locator или «города»:
— связался с сервисом строителей
— ждешь результата
в модели с сервис локатором немаловажное место занимает подтверждение о работоспособности сервиса. Особенностью модели DI — это требование знать специалистов. С возрастанием(разрастанием) проекта (с увеличением кол-ва специалистов) — это становиться все сложней. В модели с сервисами нет явного учета специалистов(хотя он может быть добавлен) — там увеличивается глубина предоставления сервисов, приводящая к их увеличивающейся специализации.
Пример — поклеить обои. Сервис локатор должен предлагать поклеить:
— бумажные
— винил
— флизелин
— стекло
— на российских шпаклевке/клее
— на импортных шпаклевке/клее
В модели с DI ты должен сам найти дядю Васю, который умеет все вышеуказанное
Пример — сетевые запросы. SL должен предлагать:
— отслеживать наличие сети
— ранжирование запросов (картинки позднее инфы/контента)
— динамическое регулирование полосы (на 2G — 2 запроса одновременно, WiFi — 8)
— использовать кэширование или без
— группирование запросов — проект со 100 типов запросов это не одно и тоже что 1000 типов запросов
Можно конечно собрать спецов по всему этому и попробовать их объединить. Но уж лучше сразу иметь сервис — просто отправки запросов, который это делает на автомате
В добавок — сервис сетевых запросов должен учитывать — потерю заказчика(приемника инфы/данных сетевых запросов) и последующую за этим отмену(или оставление выполнения) всех запросов заказчика. При этом должны быть продуманы средства доставки данных всех выполненных запросов заказчика при его появлении (например посредством аналога электронной почты).
Спасибо, интересно почитать.
В рантайме зависимости, конечно, страшновато — но это смотреть по статистике надо. На 20 млн пользователей её удобно набирать :)

В Кодеине есть какая-нибудь поддержка, аналогичная subcomponent-ам в Даггере? Очень уж удобно с ними ненужные объекты за собой убирать.
Sign up to leave a comment.