Опенсорс-библиотека Implicits от Яндекс Браузера: новый шаг в передаче зависимостей Swift

Когда iOS‑приложение вырастает до сотен тысяч строк, появляется проблема: добавление зависимости в глубокий компонент требует изменений во всех промежуточных функциях. Эти функции зависимость не используют — они просто передают её дальше. Сигнатуры разбухают, рефакторинг превращается в массовую правку файлов, и значительная часть кода становится техническим шумом. Проблема известна. Scala использует implicit parameters на уровне языка, Kotlin экспериментирует с context receivers, Android полагается на Dagger. А Swift не предлагает встроенного решения. Поэтому мы в команде Яндекс Браузера создали библиотеку Implicits — механизм неявной передачи зависимостей с compile‑time‑проверками. Она успешно работает в продакшне Браузера на полутора миллионах строк Swift‑кода, а ещё доступна в опенсорсе. В этой статье я расскажу о поиске собственного подхода для передачи зависимостей в коде на Swift, о том, как внедрение Implicits позволяет существенно сократить boilerplate, ускорить рефакторинг и улучшить читаемость кода благодаря локальному объявлению только реально используемых зависимостей, а также покажу реальные примеры из продакшн‑кода мобильной версии Яндекс Браузера.

https://habr.com/ru/companies/yandex/articles/976898/

#ios #dependency_inversion #dependency_injection #опенсорс_яндекса #swift #b #библиотека

Компактный runtime-DI для Java: JSR-330, Class-File API и миграция за 2 дня

Когда начинал разработку системы многомерного анализа данных временных рядов Dimension-UI , для внедрения зависимостей в исходном коде решил использовать Dagger 2. Практический опыт показал, что для приложений с большим количеством динамически создаваемых объектов инверсия зависимостей, реализованная в Dagger 2, не подходит. Да, создание графа зависимостей в compile-time — это, во-первых, очень быстро, и, во-вторых, удобно: получаешь сообщения об ошибках конфигурации уже при компиляции. Но накладные расходы на сопровождение всего этого хозяйства – прямо скажем, это боль. Чтобы реализовать scope-зависимости, приходится писать и поддерживать много инфраструктурного кода внутри объектов, куда мы внедряем зависимости. В Dagger 2 такая реализация, во-первых, «загрязняет» код, а во-вторых, серьезно осложняет тестирование. Изолировать методы удобным способом не получается: в тестах нужно писать очень много кода, чтобы прокинуть необходимый контекст и корректно мокировать внешние зависимости. Я туда просто не полез — покрывал unit- и UI-тестами только базовую функциональность, где были Singleton-зависимости. Даже с одними Singleton’ами приходится поднимать отдельную тестовую инфраструктуру для запуска приложения в тестовом режиме. Это не просто неудобно — это очень затратно по времени. Если сравнить усилия, которые надо потратить на реализацию тестирования подобного функционала в Spring и Dagger… Сравнение будет не в пользу Dagger. В целом я начал думать о переходе на runtime-генерацию графа зависимостей.

https://habr.com/ru/articles/962326/

#java #dagger2 #dependency_injection #dependency_inversion #DimensionDI #DimensionUI #spring_ioc #guice #рефакторинг

FastAPI и Dependency Injection: правда или вымысел?

В свое время FastAPI прогремел как гром среди ясного неба - тут тебе и минималистичный API аля- Flask (все устали от Django , диктующего свои правила), и OpenAPI документация из коробки, и удобное тестирование, и хайповая асинхронность. Буквально все, что нужно для свободы творчества, и никаких ограничений! Да еще и Depends завезли! В тот момент это был культрурный шок - Dependency Injection в Python ? Разве это не что-то из Java ? Но дьявол кроется в деталях. А вы уверены, что те самые Depends == Dependency Injection ? Уверены, что пишете код на FastAPI правильно? В рамках статьи мы рассмотрим различные подходы к организации зависимостей в рамках FastAPI проекта, оценим их с точки зрения удобства использования и постараемся разобраться, как же все-таки "правильно" готовить DI в FastAPI . Давайте разбираться

https://habr.com/ru/articles/867040/

#fastapi #dishka #dependency_injection #dependency_inversion #solid #clean_architecture #python #web