Dependency Injection: qué es, inyección de dependencias en iOS y Android

Qué es Dependency Injection: esencia y tipos de DI

Dependency Injection es una técnica mediante la cual un objeto recibe dependencias (servicios, repositorios, configuraciones) a través de un constructor, setter o interfaz, en lugar de crearlas él mismo con new. El objetivo de DI es reducir el acoplamiento entre clases. Si una clase crea dependencias por sí misma, está fuertemente vinculada a implementaciones concretas, lo que dificulta las pruebas y la modificación. Con DI, la clase trabaja con una abstracción (protocolo/interfaz) y la implementación concreta se proporciona desde el exterior.

Tres formas de inyección — Constructor Injection (a través de init/constructor), Setter Injection (a través de propiedad/setter), Interface Injection (a través de un método de interfaz). Constructor Injection es el método preferido: las dependencias son claramente visibles en la firma y el objeto siempre se crea en un estado válido. Setter Injection se usa para dependencias opcionales con valor predeterminado. Interface Injection es raro, principalmente para contenedores DI.

Contenedor DI — una biblioteca que gestiona la creación y el ciclo de vida de las dependencias. El contenedor contiene registros de tipos (cada tipo abstracto asignado a una implementación concreta) y una fábrica para crear objetos con dependencias resueltas. En Android — Dagger/Hilt, en iOS — Swinject, Needle, Dip. El contenedor puede gestionar el ámbito (scope): singleton (una instancia por aplicación), ámbito de funcionalidad (por pantalla) o un nuevo objeto en cada solicitud.

Dagger Hilt: DI para Android con generación de código

Dagger Hilt es un envoltorio sobre Dagger de Google, la biblioteca DI estándar para Android. Hilt simplifica Dagger: elimina la creación manual de componentes, añade @HiltAndroidApp, @AndroidEntryPoint y @Module. Hilt se integra con el ciclo de vida de Android: ViewModel, Activity, Fragment, Service, BroadcastReceiver pueden recibir dependencias mediante anotaciones. La generación de código ocurre en tiempo de compilación — Dagger genera implementaciones de componentes, lo que proporciona una sobrecarga de runtime cero.

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

// Module — define cómo crear dependencias
@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 recibe dependencia a través del constructor
@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 habilita DI
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    private val viewModel: MainViewModel by viewModels()
}

Componentes y ámbitos de Dagger — @Singleton (toda la aplicación), @ActivityScoped (por Activity), @FragmentScoped (por Fragment), @ViewModelScoped (por ViewModel). La elección del ámbito determina el tiempo de vida del objeto. @Singleton — una instancia por proceso, adecuado para OkHttpClient y bases de datos. @ActivityScoped — el objeto vive mientras vive la Activity, para dependencias de pantalla. @ViewModelScoped — novedad en Hilt 2.45+, el objeto vive mientras vive el ViewModel, conveniente para ámbitos de corrutinas.

Swinject: DI para iOS en Swift

Swinject es un framework DI popular de código abierto para iOS. Swinject proporciona Container, Assemblies y varios ámbitos. A diferencia de Dagger, Swinject funciona en tiempo de ejecución — las dependencias se resuelven dinámicamente sin generación de código. Esto hace que Swinject sea más fácil de configurar, pero la depuración es más difícil: un error de dependencia no resuelta solo aparece en tiempo de ejecución. Swinject admite Constructor Injection, Property Injection y Method Injection.

import Swinject

// Assembly — un grupo de registros
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 mediante 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
        }
    }
}

// Configuración de DI en AppDelegate o App
let assembler = Assembler([NetworkAssembly(), ServiceAssembly()])
let viewModel = assembler.resolver.resolve(ProfileViewModel.self)!

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

Ámbitos de Swinject — .transient (nuevo objeto cada vez), .container (singleton por contenedor), .graph (por defecto — el objeto se comparte dentro de un mismo grafo de dependencias). Para aplicaciones iOS, .container y .transient son suficientes. Swinject también admite Assembler — agrupación de Assembly para una arquitectura modular. Para pruebas, Assembly se reemplaza por MockAssembly, lo que permite la sustitución de dependencias sin cambiar el código de producción.

Comparación de DI con Service Locator e inyección manual

DI vs Service Locator — ambos patrones resuelven la gestión de dependencias, pero de manera diferente. DI inyecta dependencias en el objeto; Service Locator proporciona un registro global del que el objeto solicita las dependencias por sí mismo. DI declara explícitamente las dependencias a través del constructor (o setter). Service Locator oculta las dependencias — se solicitan dentro del método, lo que hace que la firma sea menos informativa. DI es más fácil de probar: basta con pasar un mock al constructor. Service Locator requiere configurar el registro global para cada prueba.

DI vs inyección manual — sin contenedor DI, las dependencias se crean manualmente en fábricas o AppDelegate. Para 5-10 clases, la inyección manual es más simple — no requiere aprender Dagger o Swinject. Para 50+ clases, la inyección manual se vuelve problemática: constructores con 5-6 parámetros, orden de creación complejo, duplicación de código. Un contenedor DI automatiza estos procesos y proporciona una gestión clara del ciclo de vida. La inyección manual sin contenedor es una buena opción para proyectos pequeños y prototipos.

Mejores prácticas de Dependency Injection

Constructor Injection — estándar. Utilice siempre Constructor Injection para dependencias obligatorias. Esto hace que las dependencias sean explícitas y el objeto esté siempre listo para funcionar. Setter Injection — solo para dependencias opcionales (por ejemplo, delegate o listener). Interface Injection — no lo use a menos que esté escribiendo su propia biblioteca DI. Constructor Injection es la única forma de garantizar que un objeto se cree en un estado válido.

Una clase — una responsabilidad. Si el constructor de una clase requiere 5+ parámetros, probablemente la clase viola el Principio de Responsabilidad Única. Divida la clase en varias con menos dependencias. Una señal: si escribe una clase ServiceManager con 6 servicios diferentes — esto es el antipatrón God Object. Extraiga la lógica de negocio en Use Cases (Interactors), cada uno con 1-2 dependencias.

// ❌ Malo: 6 dependencias — 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
)

// ✅ Bueno: Use Cases con 1-2 dependencias
class ProfileViewModel @Inject constructor(
    private val loadProfileUseCase: LoadProfileUseCase,
    private val trackAnalyticsUseCase: TrackAnalyticsUseCase
)

Ámbito y ciclo de vida — elija el ámbito correcto para cada dependencia. Singletons: OkHttpClient, base de datos, SharedPreferences. Ámbito de funcionalidad: repositorios, Use Cases (si no tienen estado). Transient: Value Objects, DateFormatter, analizadores. Los errores de ámbito son un problema común: un singleton que almacena el estado de la pantalla provoca fugas. En Android, @ActivityScoped de Hilt resuelve esto; en Swinject, use .container con precaución.