Injection de dépendances en Swift : principes et exemples pour iOS/macOS

Introduction à l'Injection de Dépendances en Swift

L'Injection de Dépendances (DI) est l'un des principes de conception clés qui aide à créer des applications flexibles, testables et maintenables en Swift. Dans le contexte du développement iOS et macOS, la DI permet de séparer la création des objets de leur utilisation, ce qui simplifie considérablement les tests et la modification du code.

L'idée principale est qu'une classe ne doit pas créer elle-même ses dépendances. Au lieu de cela, les dépendances sont « injectées » de l'extérieur. C'est une implémentation du principe d'Inversion des Dépendances (Dependency Inversion Principle) du SOLID.

Pourquoi l'Injection de Dépendances est-elle importante pour le développement iOS/macOS ?

Dans les applications natives en Swift, on rencontre souvent le problème du couplage fort (tight coupling). Considérons un exemple typique :

class UserService {    let networkManager = NetworkManager()    let database = Database()        func fetchUser(id: Int) -> User {        // logique    }}

Ici, UserService est fortement lié aux implémentations spécifiques de NetworkManager et Database. Cela crée plusieurs problèmes :

• Difficulté de test — impossible de remplacer les services réels par des mocks ou des stubs
• Faible réutilisabilité — la classe ne peut pas être utilisée avec d'autres implémentations
• Violation du SRP — la classe ne s'occupe pas seulement de la logique métier, mais aussi de la création des dépendances

L'Injection de Dépendances résout ces problèmes en permettant d'injecter les dépendances via le constructeur, les propriétés ou les méthodes.

Façons d'implémenter l'Injection de Dépendances en Swift

1. Injection par constructeur (Constructor Injection)

La méthode la plus courante et recommandée. Les dépendances sont transmises via l'initialiseur :

protocol NetworkService {    func request(endpoint: String) -> Data}

protocol DatabaseService {    func save(user: User)}

class UserService {    private let networkService: NetworkService    private let databaseService: DatabaseService        init(networkService: NetworkService, databaseService: DatabaseService) {        self.networkService = networkService        self.databaseService = databaseService    }        func fetchUser(id: Int) -> User? {        let data = networkService.request(endpoint: "users/\\(id)")        // parsing des données        return User(id: id, name: "John")    }}

Avantages : les dépendances sont clairement visibles, obligatoires pour le fonctionnement de la classe, faciles à tester.

2. Injection par propriété (Property Injection)

Les dépendances sont définies après la création de l'objet :

class AuthManager {    var networkService: NetworkService?        func login(username: String, password: String) -> Bool {        guard let service = networkService else { return false }        // logique d'authentification        return true    }}

// Utilisationlet authManager = AuthManager()authManager.networkService = RealNetworkService()

Inconvénient : les dépendances peuvent ne pas être définies, ce qui entraîne des types optionnels et des crashs potentiels.

3. Injection par méthode (Method Injection)

La dépendance est transmise directement dans la méthode :

class DataProcessor {    func process(data: Data, using service: NetworkService) -> ProcessedData {        let result = service.request(endpoint: "process")        // traitement        return ProcessedData()    }}

Convient pour les cas où la dépendance n'est nécessaire que pour une seule méthode.

Exemple pratique : application de gestion de tâches

Créons une application iOS simple utilisant la DI :

// Protocoles de dépendancesprotocol TaskRepository {    func fetchTasks() ->