Что использовал для реализации DI

Подходы к Dependency Injection (DI) в Android-разработке

В моей практике я использовал несколько подходов к внедрению зависимостей, эволюционируя от ручной реализации к использованию специализированных библиотек. Вот основные методы, которые я применял:

1. Ручное внедрение зависимостей (Manual DI)

На начальном этапе или в небольших проектах я использовал ручное внедрение через конструкторы и сеттеры:

class UserRepository(private val apiService: ApiService, 
                     private val database: AppDatabase) {
    
    fun getUser(userId: String): User {
        // Использование зависимостей
        val remoteUser = apiService.getUser(userId)
        database.saveUser(remoteUser)
        return remoteUser
    }
}

// Создание зависимостей вручную
val apiService = Retrofit.Builder()
    .baseUrl("https://api.example.com/")
    .build()
    .create(ApiService::class.java)

val database = Room.databaseBuilder(context, AppDatabase::class.java, "app-db").build()
val repository = UserRepository(apiService, database)

2. Использование Service Locator

Для более сложных проектов я применял паттерн Service Locator с кастомной реализацией:

object ServiceLocator {
    private val services = mutableMapOf<Class<*>, Any>()
    
    fun <T : Any> register(serviceClass: Class<T>, instance: T) {
        services[serviceClass] = instance
    }
    
    @Suppress("UNCHECKED_CAST")
    fun <T> get(serviceClass: Class<T>): T {
        return services[serviceClass] as? T
            ?: throw IllegalStateException("Service ${serviceClass.simpleName} not registered")
    }
}

// Регистрация зависимостей
ServiceLocator.register(ApiService::class.java, createApiService())
ServiceLocator.register(AppDatabase::class.java, createDatabase())

// Получение зависимостей
val repository = UserRepository(
    ServiceLocator.get(ApiService::class.java),
    ServiceLocator.get(AppDatabase::class.java)
)

3. Dagger 2 / Hilt

В большинстве современных проектов я использую Dagger 2 и его Android-специализированную версию Hilt, который стал стандартом де-факто в Android-разработке:

// Модуль для предоставления зависимостей
@Module
@InstallIn(SingletonComponent::class)
object AppModule {
    
    @Provides
    @Singleton
    fun provideApiService(): ApiService {
        return Retrofit.Builder()
            .baseUrl("https://api.example.com/")
            .build()
            .create(ApiService::class.java)
    }
    
    @Provides
    @Singleton
    fun provideDatabase(@ApplicationContext context: Context): AppDatabase {
        return Room.databaseBuilder(
            context,
            AppDatabase::class.java,
            "app-db"
        ).build()
    }
}

// Внедрение зависимостей через Hilt
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    
    @Inject
    lateinit var userRepository: UserRepository
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // userRepository уже инициализирован Hilt
    }
}

4. Koin

В Kotlin-ориентированных проектах иногда использовал Koin за его простоту и лаконичный DSL:

// Определение модуля
val appModule = module {
    single { createApiService() }
    single { createDatabase() }
    factory { UserRepository(get(), get()) }
}

// Инициализация в Application
class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidContext(this@MyApp)
            modules(appModule)
        }
    }
}

// Получение зависимостей
class MyViewModel : ViewModel() {
    private val userRepository: UserRepository by inject()
}

Критерии выбора подхода

При выборе подхода к DI я руководствуюсь следующими критериями:

• Размер и сложность проекта: для маленьких проектов часто достаточно ручного DI, тогда как для крупных enterprise-приложений предпочтителен Dagger/Hilt
• Команда и опыт: если команда хорошо знает Dagger, выбираем Hilt; если нужна быстрая адаптация - Koin
• Производительность: Dagger имеет преимущество за счет генерации кода во время компиляции
• Тестируемость: все подходы поддерживают тестирование, но Dagger/Hilt предоставляют наиболее гибкие механизмы для замены зависимостей в тестах
• Интеграция с Android Architecture Components: Hilt имеет лучшую интеграцию с ViewModel, WorkManager и другими компонентами Jetpack

Лучшие практики, которые я применяю

1. Внедрение через конструктор для обязательных зависимостей
2. Использование интерфейсов для уменьшения связанности
3. Скоупирование зависимостей (Singleton, ActivityScope, ViewModelScope)
4. Модульная организация DI-графа
5. Интеграция с MVVM/MVI архитектурами
6. Тестирование с fake-зависимостями через DI-контейнер

В текущих проектах я преимущественно использую Hilt как наиболее сбалансированное решение, сочетающее мощь Dagger с удобством для Android-разработки.