Что это простыми словами
Dagger 2 — это автоматический сборщик конструктора для приложения.
Аналогия: представьте, что вы собираете велосипед. Вам нужны колёса, руль, рама, цепь — и каждая деталь, в свою очередь, требует гаек, болтов, подшипников. Можно собирать вручную, но легко ошибиться: забыть деталь, перепутать порядок, взять не ту версию. Dagger 2 — это автоматический сборщик: вы говорите «мне нужен велосипед», а он сам находит все детали, собирает их в правильном порядке и отдаёт готовый результат.
В программировании эти «детали» называются зависимостями: одна часть кода использует другую. Dagger 2 автоматически создаёт их и подставляет туда, где нужно, избавляя разработчика от ручной сборки.
Официальное определение
Теперь, когда суть понятна, вот как Dagger 2 описывают в вакансиях и документации. Эту формулировку вы встретите у заказчика и в резюме — и теперь будете понимать, что за ней стоит.
«Dagger 2 — compile-time фреймворк для внедрения зависимостей (Dependency Injection) в Java и Kotlin-приложениях, генерирующий код на этапе компиляции».
Разберём по словам. «Внедрение зависимостей» (Dependency Injection, DI) — это и есть автоматическая подстановка тех самых «деталей», о которых мы говорили выше. «Compile-time» значит, что Dagger 2 создаёт весь нужный код заранее, ещё до запуска приложения, а не на ходу — поэтому работает быстро и ловит ошибки сразу. «Генерирующий код» означает, что библиотека сама пишет за разработчика кучу скучного технического кода.
Какую задачу решает
Когда приложение маленькое, создавать объекты можно вручную прямо в коде. Но в реальных проектах одни части зависят от других: экрану нужен доступ к сети, сеть требует настройки, настройка зависит от хранилища данных — и так по цепочке. Без Dagger 2 разработчику приходится самому прописывать всю эту цепочку в каждом месте, где что-то нужно. Это долго, однообразно и чревато ошибками.
Dagger 2 берёт эту работу на себя: разработчик один раз описывает правила («как собирать велосипед»), а дальше библиотека автоматически создаёт нужные объекты и подставляет их туда, где требуется. Код становится короче, понятнее, и меньше шансов что-то забыть.
Побочная польза: проще тестировать. Вместо реальной сети можно подставить имитацию — Dagger 2 сам подхватит подмену.
К какой экосистеме относится
Языки — Kotlin и Java. Чаще встречается в Kotlin-проектах.
Специальность — Android-разработчик (mobile). Иногда встречается в backend на Kotlin, но это редкость. Подавляющее большинство вакансий с Dagger 2 — это именно мобильная разработка.
Экосистема — в Android-проектах Dagger 2 работает рядом с другими библиотеками: Retrofit и OkHttp для сети, Glide или Coil для картинок, Jetpack для интерфейса. Сам Dagger 2 отвечает только за внедрение зависимостей, а не за весь функционал приложения.
Чем заменяется
Dagger 2 — не единственный инструмент для внедрения зависимостей. Ту же задачу решают Hilt (надстройка над Dagger 2, созданная Google специально для Android), Koin (более простая альтернатива) и менее популярные Toothpick, Kodein.
Главное: переход между ними дешёвый. Разработчик, который работал с Dagger 2, разберётся в Koin или Hilt за несколько дней — идея у них одна, отличается только синтаксис и удобство. Это не разные профессии и даже не разные школы, а скорее разные инструменты, делающие одну работу.
Hilt стоит упомянуть отдельно: это официальная рекомендация Google для Android, проще в настройке, чем чистый Dagger 2, но внутри использует тот же Dagger 2. Если в резюме написано Hilt, значит человек работал с Dagger 2, просто в более удобной обёртке.
Что не путать
Dagger 2 ≠ Kotlin. Kotlin — это язык, а Dagger 2 — лишь одна из библиотек для него.
Dagger 2 ≠ Dagger 1. Это две разные библиотеки. Dagger 2 — полная переработка, современная и быстрая. Новые проекты используют Dagger 2, но Dagger 1 ещё встречается в поддержке старых Android-приложений.
Dagger 2 ≠ Hilt как разные технологии. Hilt построен поверх Dagger 2 и упрощает его настройку для Android. Опыт с одним легко переносится на другой.
Dagger 2 ≠ Retrofit или OkHttp. Retrofit и OkHttp отвечают за работу с сетью, а Dagger 2 — за то, чтобы эти библиотеки правильно создавались и подставлялись в нужные места. Они работают вместе, а не вместо друг друга.
Dagger 2 ≠ фреймворк в строгом смысле. Хотя в вакансиях его иногда называют фреймворком для DI, технически это библиотека: она не диктует структуру всего приложения, а решает одну конкретную задачу — внедрение зависимостей.
Насколько это важно при отборе
Короткий ответ: обычно это НЕ повод отбраковывать кандидата.
Самая частая ошибка новичка-рекрутера — искать строго «Kotlin + Dagger 2» и отсеивать сильного Android-разработчика, у которого в резюме указан Koin или Hilt. Он освоит Dagger 2 за несколько дней, потому что задача та же. Отсеивая по конкретной библиотеке для DI, вы теряете хороших людей и затягиваете поиск.
Правильный подход: смотрите, есть ли у кандидата опыт с любым инструментом для внедрения зависимостей. Если есть — этого достаточно. Если в вакансии жёстко написано «только Dagger 2», уточните у нанимающего менеджера, действительно ли это принципиально: часто оказывается, что нет.
Когда всё же стоит обратить внимание: если у кандидата вообще нигде не упомянут ни один инструмент для DI (Dagger 2, Hilt, Koin), а вакансия предполагает большой сложный проект — это повод спросить, как он управлял зависимостями в приложениях. В крупных Android-проектах без DI не обойтись.
Это общий ориентир. В разных компаниях требования отличаются, поэтому всегда сверяйтесь с текстом конкретной вакансии.