Dependency Injection: co to jest, wstrzykiwanie zależności w iOS i Android

Czym jest Dependency Injection: istota i rodzaje DI

Dependency Injection — technika, w której obiekt otrzymuje zależności (serwisy, repozytoria, konfiguracje) przez konstruktor, setter lub interfejs, zamiast tworzyć je sam przez new. Celem DI jest zmniejszenie powiązania (coupling) między klasami. Jeśli klasa sama tworzy zależności, jest sztywno związana z konkretnymi implementacjami, co utrudnia testowanie i modyfikację. Przy DI klasa pracuje z abstrakcją (protocol/interface), a konkretna implementacja jest dostarczana z zewnątrz.

Trzy sposoby wstrzykiwania — Constructor Injection (przez init/constructor), Setter Injection (przez właściwość/setter), Interface Injection (przez metodę interfejsu). Constructor Injection — preferowany sposób: zależności są jawnie widoczne w sygnaturze, obiekt zawsze tworzony jest w prawidłowym stanie. Setter Injection stosuje się dla opcjonalnych zależności z wartością domyślną. Interface Injection — rzadko, głównie dla kontenerów DI.

Kontener DI — biblioteka zarządzająca tworzeniem i cyklem życia zależności. Kontener zawiera rejestrację typów (każdy abstrakcyjny typ jest mapowany na konkretną implementację) oraz fabrykę do tworzenia obiektów z rozwiązanymi zależnościami. W Android — Dagger/Hilt, w iOS — Swinject, Needle, Dip. Kontener może zarządzać zakresem (Scope): singleton (jedna instancja na aplikację), zakres funkcji (na ekran) lub nowy obiekt przy każdym żądaniu.

Dagger Hilt: DI dla Android z kodogeneracją

Dagger Hilt — nakładka na Dagger od Google, standardowa biblioteka DI dla Android. Hilt upraszcza Dagger: usuwa ręczne tworzenie komponentów, dodaje @HiltAndroidApp, @AndroidEntryPoint i @Module. Hilt integruje się z cyklem życia Android: ViewModel, Activity, Fragment, Service, BroadcastReceiver mogą otrzymywać zależności przez adnotacje. Kodogeneracja odbywa się na etapie kompilacji — Dagger generuje implementacje komponentów, co daje zerowy narzut runtime.

// Application class
@HiltAndroidApp
class MyApp : Application()

// Module — definiuje, jak tworzyć zależności
@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {
    @Provides
    @Singleton
    fun provideOkHttpClient(): OkHttpClient = OkHttpClient.Builder().build()

    @Provides
    @Singleton
    fun provideApiService(client: OkHttpClient): ApiService {
        return Retrofit.Builder()
            .baseUrl("https://api.example.com")
            .client(client)
            .build()
            .create(ApiService::class.java)
    }
}

// ViewModel otrzymuje zależność przez konstruktor
@HiltViewModel
class MainViewModel @Inject constructor(
    private val apiService: ApiService
) : ViewModel() {
    private val _state = MutableStateFlow(MainState.Loading)
    val state: StateFlow<MainState> = _state.asStateFlow()

    fun loadData() {
        viewModelScope.launch {
            _state.value = MainState.Success(apiService.getData())
        }
    }
}

// Activity — @AndroidEntryPoint włącza DI
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    private val viewModel: MainViewModel by viewModels()
}

Komponenty Dagger i zakresy widoczności — @Singleton (na całą aplikację), @ActivityScoped (na Activity), @FragmentScoped (na Fragment), @ViewModelScoped (na ViewModel). Wybór zakresu określa czas życia obiektu. @Singleton — jedna instancja na proces, odpowiednia dla OkHttpClient i bazy danych. @ActivityScoped — obiekt żyje dopóki żyje Activity, dla zależności ekranowych. @ViewModelScoped — nowość Hilt 2.45+, obiekt żyje dopóki żyje ViewModel, co jest wygodne dla zakresów korutyn.

Swinject: DI dla iOS w Swift

Swinject — popularny framework DI dla iOS o otwartym kodzie źródłowym. Swinject udostępnia Container, Assemblies i różne zakresy. W przeciwieństwie do Dagger, Swinject działa w runtime — zależności są rozwiązywane dynamicznie bez kodogeneracji. To czyni Swinject prostszym w konfiguracji, ale sprawia trudności z debugowaniem: błąd nierozwiązanej zależności ujawnia się dopiero w runtime. Swinject obsługuje Constructor Injection, Property Injection i Method Injection.

import Swinject

// Assembly — grupa rejestracji
class NetworkAssembly: Assembly {
    func assemble(container: Container) {
        container.register(NetworkServiceProtocol.self) { _ in
            NetworkService()
        }.inObjectScope(.container) // singleton

        container.register(UserRepositoryProtocol.self) { r in
            UserRepository(
                networkService: r.resolve(NetworkServiceProtocol.self)!
            )
        }
    }
}

// ViewModel przez Constructor Injection
class ProfileViewModel: ObservableObject {
    private let repository: UserRepositoryProtocol

    init(repository: UserRepositoryProtocol) {
        self.repository = repository
    }

    @Published var user: User?
    func loadUser() {
        repository.fetchUser { [weak self] user in
            self?.user = user
        }
    }
}

// Konfiguracja DI w AppDelegate lub App
let assembler = Assembler([NetworkAssembly(), ServiceAssembly()])
let viewModel = assembler.resolver.resolve(ProfileViewModel.self)!

// Property Injection dla UIKit ViewController
container.register(UserViewController.self) { r in
    let vc = UserViewController()
    vc.viewModel = r.resolve(ProfileViewModel.self)
    return vc
}

Zakresy Swinject — .transient (nowy obiekt za każdym razem), .container (singleton na kontener), .graph (domyślnie — obiekt współdzielony w obrębie jednego grafu zależności). Dla aplikacji iOS wystarczające są .container i .transient. Swinject obsługuje również Assembler — grupowanie Assembly dla architektury modułowej. Do testów Assembly są zastępowane przez MockAssembly, co umożliwia podmianę zależności bez zmiany kodu produkcyjnego.

Porównanie DI z Service Locator i ręcznym wstrzykiwaniem

DI vs Service Locator — oba wzorce rozwiązują problem zarządzania zależnościami, ale w różny sposób. DI wstrzykuje zależności do obiektu, Service Locator udostępnia globalny rejestr, z którego obiekt sam pobiera zależności. DI jawnie deklaruje zależności przez konstruktor (lub setter). Service Locator ukrywa zależności — są one pobierane wewnątrz metody, co czyni sygnaturę mniej informacyjną. DI łatwiej testować: wystarczy podstawić mock do konstruktora. Service Locator wymaga konfiguracji globalnego rejestru dla każdego testu.

DI vs ręczne wstrzykiwanie — bez kontenera DI zależności są tworzone ręcznie w fabrykach lub AppDelegate. Dla 5-10 klas ręczne wstrzykiwanie jest prostsze — nie wymaga nauki Dagger ani Swinject. Dla 50+ klas ręczne wstrzykiwanie staje się problemem: konstruktory z 5-6 parametrami, skomplikowana kolejność tworzenia, powielanie kodu. Kontener DI automatyzuje te procesy i zapewnia przejrzysty lifecycle. Ręczne wstrzykiwanie bez kontenera — dobry wybór dla małych projektów i prototypów.

Najlepsze praktyki Dependency Injection

Constructor Injection — standard. Zawsze używaj Constructor Injection dla obowiązkowych zależności. To czyni zależności jawnymi, a obiekt zawsze gotowym do pracy. Setter Injection — tylko dla opcjonalnych zależności (np. delegate lub listener). Interface Injection — nie używaj, chyba że piszesz własną bibliotekę DI. Constructor Injection — jedyny sposób, aby zagwarantować, że obiekt jest tworzony w prawidłowym stanie.

Jedna klasa — jedna odpowiedzialność. Jeśli konstruktor klasy wymaga 5+ parametrów, prawdopodobnie klasa narusza Single Responsibility Principle. Podziel klasę na kilka z mniejszą liczbą zależności. Sygnał: jeśli piszesz klasę ServiceManager z 6 różnymi serwisami — to antywzorzec God Object. Wydziel logikę biznesową do Use Cases (Interactors), każdy z 1-2 zależnościami.

// ❌ Źle: 6 zależności — God Object
class ProfileViewModel @Inject constructor(
    private val api: ApiService,
    private val db: Database,
    private val analytics: Analytics,
    private val prefs: Preferences,
    private val location: LocationProvider,
    private val notification: NotificationManager
)

// ✅ Dobrze: Use Cases z 1-2 zależnościami
class ProfileViewModel @Inject constructor(
    private val loadProfileUseCase: LoadProfileUseCase,
    private val trackAnalyticsUseCase: TrackAnalyticsUseCase
)

Zakres i lifecycle — wybieraj odpowiedni zakres dla każdej zależności. Singleton: OkHttpClient, baza danych, SharedPreferences. Zakres funkcji: repozytoria, Use Cases (jeśli nie mają stanu). Transient: Value Objects, DateFormatter, parsery. Błąd zakresu — częsty problem: singleton przechowujący stan ekranu prowadzi do wycieków. W Android Hilt @ActivityScoped rozwiązuje ten problem, w Swinject — .container z ostrożnością.