Введение в внедрение зависимостей Внедрение зависимостей (DI) — это шаблон проектирования, используемый для реализации инверсии управления (IoC), где управление созданием и управлением зависимостями передается от приложения внешней сущности. Это помогает создавать более модульный, тестируемый и поддерживаемый код. Это метод, при котором ответственность за создание объектов передается другим частям кода. Это способствует слабой связанности, делая код более модульным и простым в управлении. Классам часто нужны ссылки на другие классы для правильного функционирования. Например, рассмотрим класс , которому требуется класс . Эти необходимые классы называются зависимостями. Класс зависит от наличия экземпляра класса для работы. Library Book Library Book Существует три основных способа, с помощью которых класс может получить необходимые ему объекты: : класс создает и инициализирует свои собственные зависимости. Например, класс создаст и инициализирует свой собственный экземпляр класса . Самостоятельное построение Library Book : класс извлекает зависимости из внешнего источника. Некоторые API Android, такие как getters и , работают таким образом. Внешний поиск Context getSystemService() : Зависимости предоставляются классу либо при его создании, либо через методы, которые их требуют. Например, конструктор получит экземпляр в качестве параметра. Внедрение зависимостей Library Book Третий вариант — внедрение зависимостей! С помощью DI вы предоставляете зависимости класса, а не заставляете экземпляр класса получать их самостоятельно. Пример без внедрения зависимости Без DI , создающая собственную зависимость , может выглядеть следующим образом: Library Book class Library { private Book book = new Book(); void open() { book.read(); } } public class Main { public static void main(String[] args) { Library library = new Library(); library.open(); } } Это не пример DI, поскольку класс создает свой собственный . Это может быть проблематично, потому что: Library Book : и тесно связаны. Экземпляр использует один тип , что затрудняет использование подклассов или альтернативных реализаций. Тесная связь Library Book Library Book : жесткая зависимость от усложняет тестирование. использует реальный экземпляр , предотвращая использование тестовых двойников для модификации для различных тестовых случаев. Трудности тестирования Book Library Book Book Пример с внедрением зависимости При использовании DI вместо того, чтобы каждый экземпляр создавал свой собственный объект , он получает объект в качестве параметра в своем конструкторе: Library Book Book class Library { private Book book; Library(Book book) { this.book = book; } void open() { book.read(); } } public class Main { public static void main(String[] args) { Book book = new Book(); Library library = new Library(book); library.open(); } Основная функция использует . Поскольку зависит от , приложение создает экземпляр и затем использует его для построения экземпляра . Преимущества этого подхода на основе DI следующие: Library Library Book Book Library : Вы можете передавать различные реализации в . Например, вы можете определить новый подкласс с именем , который вы хотите, чтобы использовала. С DI вы просто передаете экземпляр в , и он работает без каких-либо дополнительных изменений. Повторное использование Library Book Library Book EBook Library EBook Library : вы можете передавать тестовые дубликаты для проверки различных сценариев. Простое тестирование Library Еще один пример DI Рассмотрим сценарий, в котором класс опирается на класс . Без DI напрямую создает экземпляр , что затрудняет использование различных типов уведомлений или тестирование службы с различными реализациями уведомлений. NotificationService Notification NotificationService Notification Чтобы проиллюстрировать DI, давайте рефакторизируем этот пример: interface Notification { void send(); } class EmailNotification implements Notification { @Override public void send() { // Send email notification } } class SMSNotification implements Notification { @Override public void send() { // Send SMS notification } } class NotificationService { void sendNotification(Notification notification) { notification.send(); } } Теперь зависит от интерфейса , а не от конкретного класса. Это позволяет использовать различные реализации взаимозаменяемо. Вы можете задать реализацию, которую хотите использовать, с помощью метода : NotificationService Notification Notification sendNotification NotificationService service = new NotificationService(); service.sendNotification(new EmailNotification()); service.sendNotification(new SMSNotification()); Методы внедрения зависимостей в Android Существует три основных типа ДИ: : Зависимости передаются через методы, к которым класс может получить доступ через интерфейс или другой класс. Предыдущий пример демонстрирует метод инъекции. Метод (интерфейс) инъекции : зависимости передаются классу через его конструктор. Внедрение через конструктор class NotificationService { private final Notification notification; public NotificationService(Notification notification) { this.notification = notification; } public void sendNotification() { notification.send(); } } public class Main { public static void main(String[] args) { NotificationService service = new NotificationService(new EmailNotification()); service.sendNotification(); } } : Определенные классы фреймворка Android, такие как действия и фрагменты, создаются системой, поэтому внедрение конструктора невозможно. При внедрении поля зависимости создаются после создания класса. 3. Field Injection (или Setter Injection) class NotificationService { private Notification notification; public Notification getNotification() { return notification; } public void setNotification(Notification notification) { this.notification = notification; } public void sendNotification() { notification.send(); } } public class Main { public static void main(String[] args) { NotificationService service = new NotificationService(); service.setNotification(new EmailNotification()); service.sendNotification(); } } : зависимости предоставляются через методы, часто с использованием аннотации . 4. Внедрение метода @Inject Преимущества внедрения зависимостей Классы становятся более многоразовыми и менее зависимыми от конкретных реализаций. Это происходит из-за инверсии управления, когда классы больше не управляют своими зависимостями, а работают с любой предоставленной конфигурацией. Зависимости являются частью поверхности API и могут быть проверены при создании объекта или во время компиляции, что упрощает рефакторинг. Поскольку класс не управляет своими зависимостями, во время тестирования могут передаваться различные реализации для охвата различных сценариев. Автоматизированное внедрение зависимостей В предыдущем примере вы вручную создавали, предоставляли и управляли зависимостями различных классов без использования библиотеки. Этот подход известен как ручное внедрение зависимостей. Хотя он работает в простых случаях, он становится громоздким по мере увеличения числа зависимостей и классов. Ручное внедрение зависимостей имеет несколько недостатков: : для больших приложений управление всеми зависимостями и их правильное подключение может привести к большому количеству повторяющегося кода. В многослойной архитектуре создание объекта для верхнего слоя требует предоставления всех зависимостей для нижних слоев. Например, для сборки компьютера вам понадобятся ЦП, материнская плата, ОЗУ и другие компоненты; а ЦП может потребовать транзисторы и конденсаторы. Шаблонный код : если вы не можете заранее создать зависимости — например, с помощью ленивой инициализации или ограничения объектов определенными потоками в вашем приложении — вам необходимо написать и поддерживать пользовательский контейнер (или граф зависимостей) для управления временем существования ваших зависимостей в памяти. Сложное управление зависимостями Библиотеки могут автоматизировать этот процесс, создавая и предоставляя вам зависимости. Эти библиотеки делятся на две категории: : они связывают зависимости во время выполнения. Решения на основе рефлексии : они генерируют код для подключения зависимостей во время компиляции. Статические решения Dagger — популярная библиотека внедрения зависимостей для Java, Kotlin и Android, поддерживаемая Google. Dagger упрощает DI в вашем приложении, создавая и управляя графом зависимостей для вас. Он предоставляет полностью статические зависимости времени компиляции, решая многие проблемы разработки и производительности, связанные с решениями на основе отражения, такими как Guice. Решения, основанные на рефлексии Эти фреймворки подключают зависимости во время выполнения: : фреймворк DI времени выполнения, который использует рефлексию для соединения зависимостей. Он разработан, чтобы быть легким и быстрым, что делает его подходящим для приложений Android. Toothpick Статические решения Эти фреймворки генерируют код для подключения зависимостей во время компиляции: : Созданный на основе Dagger, Hilt предоставляет стандартный способ внедрения инъекции зависимостей Dagger в приложение Android. . Hilt Он упрощает настройку и использование Dagger, предоставляя предопределенные компоненты и области действия : легкий и простой фреймворк DI для Kotlin. Koin использует DSL для определения зависимостей и прост в настройке и использовании. Koin : DI-фреймворк на основе Kotlin, который прост в использовании и понимании. Он предоставляет простой и гибкий API для управления зависимостями. Kodein Альтернативы внедрению зависимостей Альтернативой внедрению зависимостей является шаблон локатора служб. Этот шаблон проектирования также помогает отделить классы от их конкретных зависимостей. Вы создаете класс, известный как локатор служб, который создает и хранит зависимости, предоставляя их по требованию. object ServiceLocator { fun getProcessor(): Processor = Processor() } class Computer { private val processor = ServiceLocator.getProcessor() fun start() { processor.run() } } fun main(args: Array<String>) { val computer = Computer() computer.start() } Шаблон локатора служб отличается от внедрения зависимостей тем, как потребляются зависимости. С шаблоном локатора служб классы запрашивают необходимые им зависимости; с внедрением зависимостей приложение заранее предоставляет требуемые объекты. Что такое Кинжал 2? Dagger 2 — популярный фреймворк DI для Android. Он использует генерацию кода во время компиляции и известен своей высокой производительностью. Dagger 2 упрощает процесс внедрения зависимостей, генерируя необходимый код для обработки зависимостей, сокращая шаблонный код и повышая эффективность. Dagger 2 — это библиотека на основе аннотаций для внедрения зависимостей в Android. Вот основные аннотации и их цели: : Используется для определения классов, которые предоставляют зависимости. Например, модуль может предоставить для Retrofit. @Module ApiClient : Аннотирует методы в модуле, чтобы указать, как создавать и возвращать зависимости. @Provides : Используется для запроса зависимостей. Может применяться к полям, конструкторам и методам. @Inject : Интерфейс, который связывает и . Он содержит все модули и предоставляет конструктор для приложения. @Component @Module @Inject : обеспечивает создание единственного экземпляра зависимости. @Singleton : используется в абстрактных классах для предоставления зависимостей, похоже на но более лаконично. @Binds @Provides Компоненты кинжала Dagger может генерировать график зависимостей для вашего проекта, позволяя ему определять, где получать зависимости, когда это необходимо. Чтобы включить это, вам нужно создать интерфейс и аннотировать его с помощью . @Component В интерфейсе вы определяете методы, которые возвращают экземпляры нужных вам классов (например, ). Аннотация предписывает Dagger сгенерировать контейнер со всеми зависимостями, необходимыми для удовлетворения типов, которые он выставляет. Этот контейнер называется компонентом Dagger и содержит граф объектов, которые Dagger знает, как предоставить вместе с их зависимостями. @Component BookRepository @Component Пример Давайте рассмотрим пример с использованием : LibraryRepository : добавьте аннотацию к конструктору , чтобы Dagger знал, как создать экземпляр . Аннотируйте конструктор @Inject LibraryRepository LibraryRepository public class LibraryRepository { private final LocalLibraryDataSource localDataSource; private final RemoteLibraryDataSource remoteDataSource; @Inject public LibraryRepository(LocalLibraryDataSource localDataSource, RemoteLibraryDataSource remoteDataSource) { this.localDataSource = localDataSource; this.remoteDataSource = remoteDataSource; } } : Аналогичным образом аннотируйте конструкторы зависимостей ( и ), чтобы Dagger знал, как их создавать. 2. Аннотируйте зависимости LocalLibraryDataSource RemoteLibraryDataSource public class LocalLibraryDataSource { @Inject public LocalLibraryDataSource() { // Initialization code } } public class RemoteLibraryDataSource { private final LibraryService libraryService; @Inject public RemoteLibraryDataSource(LibraryService libraryService) { this.libraryService = libraryService; } } : создайте интерфейс, аннотированный , для определения графа зависимостей. 3. Определите компонент @Component @Component public interface ApplicationComponent { LibraryRepository getLibraryRepository(); } При сборке проекта Dagger генерирует для вас реализацию интерфейса , обычно называемую . ApplicationComponent DaggerApplicationComponent Использование Теперь вы можете использовать сгенерированный компонент для получения экземпляров ваших классов с автоматически внедренными их зависимостями: public class MainApplication extends Application { private ApplicationComponent applicationComponent; @Override public void onCreate() { super.onCreate(); applicationComponent = DaggerApplicationComponent.create(); } public ApplicationComponent getApplicationComponent() { return applicationComponent; } } В вашей активности или фрагменте вы можете получить экземпляр : LibraryRepository public class MainActivity extends AppCompatActivity { @Inject LibraryRepository libraryRepository; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); ((MainApplication) getApplication()).getApplicationComponent().inject(this); // Use the injected libraryRepository } } Ключевые концепции в Dagger 2 1. Модули ∘ Ключевые концепции модулей ∘ Включение модулей в компоненты 2. Области применения 3. Компоненты 4. Зависимости компонентов 5. Привязки во время выполнения 1. Модули Модули в Dagger 2 — это классы, аннотированные , которые предоставляют зависимости компонентам. Они содержат методы, аннотированные или , чтобы указать, как создавать и предоставлять зависимости. Модули необходимы для организации и управления созданием объектов, которые нужны вашему приложению. @Module @Provides @Binds Ключевые концепции модулей Аннотация @Module: Эта аннотация используется для определения класса как модуля Dagger. Класс модуля содержит методы, которые предоставляют зависимости. @Provides Аннотация: Эта аннотация используется в методах внутри модуля, чтобы указать, что метод предоставляет определенную зависимость. Эти методы отвечают за создание и возврат экземпляров зависимостей. Аннотация @Binds: эта аннотация используется в абстрактных классах для привязки реализации к интерфейсу. Она более лаконична, чем и используется, когда модуль является абстрактным классом. @Provides Пример модуля @Module public class NetworkModule { @Provides @Singleton Retrofit provideRetrofit() { return new Retrofit.Builder() .baseUrl("https://api.example.com") .addConverterFactory(GsonConverterFactory.create()) .build(); } @Provides @Singleton OkHttpClient provideOkHttpClient() { return new OkHttpClient.Builder() .addInterceptor(new HttpLoggingInterceptor().setLevel(HttpLoggingInterceptor.Level.BODY)) .build(); } } В этом примере — это класс, аннотированный . Он содержит два метода, аннотированные , которые создают и возвращают экземпляры и . NetworkModule @Module @Provides Retrofit OkHttpClient Использование @Binds Когда у вас есть интерфейс и его реализация, вы можете использовать для привязки реализации к интерфейсу. Это более лаконично, чем использование . @Binds @Provides public interface ApiService { void fetchData(); } public class ApiServiceImpl implements ApiService { @Override public void fetchData() { // Implementation } } @Module public abstract class ApiModule { @Binds abstract ApiService bindApiService(ApiServiceImpl apiServiceImpl); } В этом примере — абстрактный класс, аннотированный . Метод аннотирован для привязки к . ApiModule @Module bindApiService @Binds ApiServiceImpl ApiService Модули можно организовать на основе предоставляемой ими функциональности. Например, можно иметь отдельные модули для сетевых операций, операций с базой данных и зависимостей, связанных с пользовательским интерфейсом. Пример: : предоставляет сетевые зависимости, такие как и . NetworkModule Retrofit OkHttpClient : предоставляет зависимости, связанные с базой данных, такие как . DatabaseModule RoomDatabase : предоставляет зависимости, связанные с пользовательским интерфейсом, такие как и . UIModule ViewModel Presenter Включение модулей в компоненты Модули включены в компоненты для предоставления зависимостей классам, которым они нужны. Вот как это можно настроить: ApplicationComponent.java: @Singleton @Component(modules = {NetworkModule.class, DatabaseModule.class}) public interface ApplicationComponent { void inject(MyApplication application); } В этом примере включает и для предоставления зависимостей приложению. ApplicationComponent NetworkModule DatabaseModule 2. Области применения Области действия в Dagger 2 — это аннотации, которые определяют жизненный цикл зависимостей. Они гарантируют, что один экземпляр зависимости создается и совместно используется в указанной области действия. Это помогает эффективно управлять памятью и гарантировать повторное использование зависимостей там, где это уместно. : обеспечивает единственный экземпляр зависимости на протяжении всего жизненного цикла приложения. Область действия Singleton : обеспечивает единственный экземпляр зависимости в жизненном цикле действия. Область действия : обеспечивает единственный экземпляр зависимости в жизненном цикле фрагмента. Область действия фрагмента 1. Область действия синглтона : Область действия гарантирует, что будет создан и совместно использован на протяжении всего жизненного цикла приложения один экземпляр зависимости. Определение @Singleton Эта область действия обычно используется для зависимостей, которые должны быть общими для всего приложения, например, сетевые клиенты, экземпляры баз данных или общие настройки. Пример: @Singleton @Component(modules = {NetworkModule.class, DatabaseModule.class}) public interface ApplicationComponent { void inject(MyApplication application); } В этом примере аннотация гарантирует, что экземпляры и , предоставляемые и являются синглтонами и используются совместно во всем приложении. @Singleton Retrofit Database NetworkModule DatabaseModule 2. Область деятельности : (настраиваемая область действия) гарантирует, что в жизненном цикле действия будет создан и совместно использован один экземпляр зависимости. Определение @ActivityScope Эта область полезна для зависимостей, которые являются специфичными для действия и должны воссоздаваться каждый раз при повторном создании действия, например, для презентаторов или моделей представлений. : Пример @Scope @Retention(RetentionPolicy.RUNTIME) public @interface ActivityScope { } @ActivityScope @Component(dependencies = ApplicationComponent.class, modules = ActivityModule.class) public interface ActivityComponent { void inject(MainActivity mainActivity); } В этом примере аннотация гарантирует, что зависимости, предоставляемые , ограничены жизненным циклом действия. @ActivityScope ActivityModule 3. Область действия фрагмента : (еще одна настраиваемая область действия) гарантирует, что в жизненном цикле фрагмента создается и совместно используется один экземпляр зависимости. Определение @FragmentScope Вариант использования: эта область полезна для зависимостей, которые специфичны для фрагмента и должны воссоздаваться каждый раз при воссоздании фрагмента, например, презентаторы или модели представлений, специфичные для фрагмента. : Пример @Scope @Retention(RetentionPolicy.RUNTIME) public @interface FragmentScope { } @FragmentScope @Component(dependencies = ActivityComponent.class, modules = FragmentModule.class) public interface FragmentComponent { void inject(MyFragment myFragment); } В этом примере аннотация гарантирует, что зависимости, предоставляемые ограничены жизненным циклом фрагмента. @FragmentScope FragmentModule 3. Компоненты Зависимости компонентов позволяют одному компоненту зависеть от другого, позволяя повторно использовать зависимости. Существует два основных типа зависимостей компонентов: : обеспечивает зависимости, необходимые для всего приложения. Компонент приложения : обеспечивает зависимости, необходимые в рамках определенного действия. Компонент действия 1. Компонент приложения : Компонент приложения предоставляет зависимости, которые необходимы во всем приложении. Обычно он ограничен , чтобы гарантировать, что зависимости являются общими для всего приложения. Определение @Singleton Этот компонент используется для зависимостей, которые должны быть доступны глобально, например, сетевые клиенты, экземпляры баз данных или общие настройки. : Пример @Singleton @Component(modules = {NetworkModule.class, DatabaseModule.class}) public interface ApplicationComponent { void inject(MyApplication application); } В этом примере отвечает за предоставление экземпляров и , которые являются общими для всего приложения. ApplicationComponent Retrofit Database 2. Компонент активности : Компонент Activity предоставляет зависимости, необходимые в рамках определенной активности. Обычно он ограничен пользовательской областью действия, например , чтобы гарантировать, что зависимости будут воссоздаваться каждый раз при воссоздании активности. Определение @ActivityScope Этот компонент используется для зависимостей, специфичных для определенной деятельности, таких как презентаторы или модели представлений. : Пример @ActivityScope @Component(dependencies = ApplicationComponent.class, modules = ActivityModule.class) public interface ActivityComponent { void inject(MainActivity mainActivity); } В этом примере зависит от и предоставляет зависимости, специфичные для . ActivityComponent ApplicationComponent MainActivity 4. Зависимости компонентов Зависимости компонентов позволяют одному компоненту зависеть от другого, позволяя повторно использовать зависимости. Существует два основных типа зависимостей компонентов: : Подкомпонент является дочерним элементом другого компонента и может получать доступ к зависимостям своего родителя. Подкомпоненты : позволяет компоненту зависеть от другого компонента, не будучи при этом подкомпонентом. Атрибут зависимости 1. Подкомпоненты: Подкомпонент является дочерним элементом другого компонента и может иметь доступ к зависимостям своего родителя. Подкомпоненты определяются внутри родительского компонента и могут наследовать его область действия. : Пример @ActivityScope @Subcomponent(modules = ActivityModule.class) public interface ActivitySubcomponent { void inject(MainActivity mainActivity); } В этом примере является подкомпонентом родительского компонента и может получать доступ к его зависимостям. ActivitySubcomponent 2. Атрибут зависимости Это позволяет компоненту зависеть от другого компонента, не будучи подкомпонентом. Зависимый компонент может получить доступ к зависимостям, предоставляемым родительским компонентом. : Пример @ActivityScope @Component(dependencies = ApplicationComponent.class, modules = ActivityModule.class) public interface ActivityComponent { void inject(MainActivity mainActivity); } В этом примере зависит от и может получить доступ к его зависимостям. ActivityComponent ApplicationComponent 5. Привязки во время выполнения Привязки времени выполнения в Dagger 2 относятся к предоставлению зависимостей, которые создаются и управляются во время выполнения на основе контекста, в котором они необходимы. : используется для зависимостей, которые должны существовать столько же, сколько и приложение. Контекст приложения : используется для зависимостей, которые должны существовать столько же, сколько и активность. Контекст активности 1. Контекст приложения : Контекст приложения — это контекст, привязанный к жизненному циклу всего приложения. Он используется для зависимостей, которые должны существовать так же долго, как и само приложение. Определение Зависимости, которые являются общими для всего приложения и не требуют повторного создания для каждой активности или фрагмента. Примерами являются сетевые клиенты, экземпляры баз данных и общие настройки. : Пример @Module public class AppModule { private final Application application; public AppModule(Application application) { this.application = application; } @Provides @Singleton Application provideApplication() { return application; } @Provides @Singleton Context provideApplicationContext() { return application.getApplicationContext(); } } В этом примере предоставляет контекст приложения как одноэлементную зависимость. Метод гарантирует, что предоставленный контекст привязан к жизненному циклу приложения. AppModule provideApplicationContext 2. Контекст деятельности : Контекст активности — это контекст, привязанный к жизненному циклу определенной активности. Он используется для зависимостей, которые должны существовать так же долго, как и сама активность. Определение Зависимости, которые являются специфическими для активности и должны быть созданы заново каждый раз при повторном создании активности. Примерами являются модели представлений, презентаторы и зависимости, связанные с пользовательским интерфейсом. : Пример @Module public class ActivityModule { private final Activity activity; public ActivityModule(Activity activity) { this.activity = activity; } @Provides @ActivityScope Activity provideActivity() { return activity; } @Provides @ActivityScope Context provideActivityContext() { return activity; } } В этом примере предоставляет контекст активности как зависимость с областью действия. Метод гарантирует, что предоставленный контекст привязан к жизненному циклу активности. ActivityModule provideActivityContext Использование привязок времени выполнения в компонентах Чтобы использовать эти привязки времени выполнения, вам необходимо включить соответствующие модули в ваши компоненты: : Компонент приложения @Singleton @Component(modules = {AppModule.class, NetworkModule.class}) public interface ApplicationComponent { void inject(MyApplication application); Context getApplicationContext(); } : Компонент деятельности @ActivityScope @Component(dependencies = ApplicationComponent.class, modules = ActivityModule.class) public interface ActivityComponent { void inject(MainActivity mainActivity); Context getActivityContext(); } Внедрение контекстов После настройки компонентов и модулей вы можете внедрять контексты в свои классы по мере необходимости. : Пример в действии public class MainActivity extends AppCompatActivity { @Inject Context activityContext; @Inject Context applicationContext; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); ApplicationComponent appComponent = ((MyApplication) getApplication()).getApplicationComponent(); ActivityComponent activityComponent = DaggerActivityComponent.builder() .applicationComponent(appComponent) .activityModule(new ActivityModule(this)) .build(); activityComponent.inject(this); // Use the injected contexts Log.d("MainActivity", "Activity Context: " + activityContext); Log.d("MainActivity", "Application Context: " + applicationContext); } } В этом примере получает как контекст активности, так и контекст приложения через внедрение зависимости. Это позволяет активности использовать соответствующий контекст на основе конкретных потребностей зависимостей. MainActivity Пример: использование Dagger 2 в приложении Android Настройка Кинжала 2 Чтобы использовать Dagger 2 в вашем проекте, вам необходимо добавить следующие зависимости в ваш файл : build.gradle dependencies { implementation 'com.google.dagger:dagger:2.x' annotationProcessor 'com.google.dagger:dagger-compiler:2.x' } Замените на последнюю версию Dagger 2. 2.x Шаг 1: Определите модуль Создайте модуль для предоставления зависимостей. Например, для предоставления экземпляра : NetworkModule Retrofit @Module public class NetworkModule { @Provides @Singleton Retrofit provideRetrofit() { return new Retrofit.Builder() .baseUrl("https://api.example.com") .addConverterFactory(GsonConverterFactory.create()) .build(); } } Шаг 2: Определите компонент Создайте компонент для соединения модуля и классов, которым нужны зависимости: @Singleton @Component(modules = {NetworkModule.class}) public interface ApplicationComponent { void inject(MyApplication application); } Шаг 3: Внедрение зависимостей Используйте компонент для внедрения зависимостей в ваши классы. Например, в вашем классе : Application public class MyApplication extends Application { private ApplicationComponent applicationComponent; @Override public void onCreate() { super.onCreate(); applicationComponent = DaggerApplicationComponent.builder() .networkModule(new NetworkModule()) .build(); applicationComponent.inject(this); } public ApplicationComponent getApplicationComponent() { return applicationComponent; } } Шаг 4: использование внедренных зависимостей Теперь вы можете использовать внедренные зависимости в своих классах. Например, в : Activity public class MainActivity extends AppCompatActivity { @Inject Retrofit retrofit; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); ((MyApplication) getApplication()).getApplicationComponent().inject(this); // Use the injected Retrofit instance // ... } } Заключение Давайте подведем итог этой теме: Основная цель DI — ослабить связанность, что упрощает управление зависимостями. Используя DI, вы можете повысить гибкость кода и упростить процесс тестирования. DI — сложная тема с различными реализациями в зависимости от сценария. DI на разных языках имеет особенности, которые могут повлиять на то, как вы с ним работаете. Dagger 2 автоматизирует процесс создания и предоставления зависимостей, сокращая объем шаблонного кода и улучшая удобство обслуживания. Dagger 2 обеспечивает безопасность во время компиляции, гарантируя, что все зависимости будут удовлетворены до запуска приложения. Генерируя код во время компиляции, Dagger 2 позволяет избежать снижения производительности, связанного с решениями на основе рефлексии.
