Le modèle d'initialisation de Swift a été conçu pour éradiquer le comportement indéfini commun dans des langages comme Objective-C, où l'accès aux méthodes ou propriétés d'instance avant que toute la mémoire ne soit initialisée pourrait entraîner des fautes de segmentation ou des exploits de sécurité. Le problème fondamental réside dans les hiérarchies de classes : un objet sous-classe contient de la mémoire pour ses propres propriétés stockées ainsi que pour toutes les propriétés héritées, et le compilateur doit garantir qu'aucun code n'accède à cette mémoire tant que chaque octet n'est pas valide. Pour résoudre cela, Swift impose un invariant d'initialisation définitive (DI) par analyse statique, exigeant qu'un objet reste dans un état partiellement construit et non sécurisé jusqu'à ce que la phase 1 de son initialisation en deux phases soit terminée. Pendant la phase 1, l'initialiseur doit attribuer des valeurs à toutes les propriétés introduites par la classe actuelle et déléguer vers les initialisateurs de la classe parente ; seulement après que cette phase soit terminée, self peut être accédé ou échappé en toute sécurité.
class Vehicle { let wheelCount: Int init(wheels: Int) { self.wheelCount = wheels // Phase 1 terminée pour Vehicle } } class Bicycle: Vehicle { let hasBell: Bool init(bell: Bool) { // Phase 1 : Initialiser ses propres propriétés d'abord self.hasBell = bell // Puis déléguer à la classe parente super.init(wheels: 2) // Phase 1 terminée : initialisation définitive complète // Phase 2 : Sûr d'utiliser self self.checkSafety() } func checkSafety() { print("Vélo avec \(wheelCount) roues \(hasBell ? "a" : "n'a pas") de cloche") } }
Lors du développement d'une application de dossiers médicaux, nous avons été confrontés à un scénario complexe avec une superclasse PatientRecord et une sous-classe ICUPatientRecord qui nécessitait le calcul d'un score de gravité basé sur l'âge du patient (une propriété de la superclasse) pendant l'initialisation. L'implémentation initiale tentait d'appeler une méthode auxiliaire calculateSeverity()—qui accédait à self.age—avant d'invoquer super.init(age:), entraînant une erreur de compilation car l'initialiseur de la sous-classe n'avait pas encore garanti la sécurité de la mémoire héritée. Nous avons évalué trois approches architecturales distinctes pour résoudre cette contrainte.
Une approche impliquait de déclarer le score de gravité comme un optional non emballé implicite (var severity: Int!) et de reporter son affectation jusqu'à ce que l'initialisation de la superclasse soit terminée. Bien que cela ait satisfait le compilateur, cela a introduit un risque d'exécution important : la propriété pourrait être accédée avant son affectation, provoquant un crash, et cela nous a empêchés d'utiliser une déclaration immuable let, compromettant la garantie d'intégrité du dossier.
Une deuxième stratégie considérait l'utilisation d'une méthode de fabrique statique qui créerait un objet empêcheur temporaire uniquement pour lire l'âge, calculer la gravité hors ligne, puis construire l'instance réelle avec des valeurs pré-calculées. Cela préservait la sécurité mémoire mais ajoutait un surplus de code substantiel et obscurcissait le flux d'initialisation, rendant le code beaucoup plus difficile à maintenir et à déboguer pour les autres membres de l'équipe.
La solution choisie impliquait de restructurer l'initialiseur pour accepter l'âge en tant que paramètre, de calculer la gravité en utilisant une fonction statique pure qui opérait sur le paramètre d'entrée plutôt que sur la propriété d'instance, et de passer la valeur pré-calculée à un initialiseur désigné. Cette approche maintenait l'immuabilité en permettant à severity d'être une constante let, respectait strictement les règles d'initialisation en deux phases, et permettait au compilateur de vérifier la sécurité au moment de la construction plutôt qu'à l'exécution. Le résultat était une séquence d'initialisation sans crash qui exprimait clairement la dépendance de données entre l'âge et la gravité tout en tirant parti de l'analyse statique de Swift pour prévenir les régressions.
Pourquoi le compilateur empêche-t-il d'appeler des méthodes d'instance sur self même si ces méthodes sont définies dans la sous-classe et semblent sans rapport avec les propriétés de la superclasse ?
Le compilateur impose cette restriction car l'objet existe en tant que mémoire allouée, mais la portion de superclasse reste une mémoire brute non initialisée. Tout appel de méthode sur self—peu importe où il est défini—reçoit le pointeur de l'objet complet et pourrait potentiellement accéder aux champs de superclasse non initialisés par des moyens indirects, violant ainsi la sécurité mémoire. Swift traite de manière conservatrice toute utilisation de self avant la fin de la phase 1 comme non sécurisée, n'autorisant que les affectations directes aux propriétés stockées de la classe actuelle.
Comment l'analyse d'initialisation définitive gère-t-elle les propriétés de référence weak par rapport aux propriétés de référence unowned ?
Le vérificateur d'initialisation définitive traite les types optionnels, y compris les variables weak qui sont implicitement Optionnelles, comme ayant une valeur initiale valide de nil injectée automatiquement par le compilateur. Par conséquent, les propriétés weak ne nécessitent pas d'initialisation explicite dans les initialisateurs. À l'inverse, les références unowned sont non-optionnelles et supposent une sémantique non nulle immédiate ; par conséquent, elles doivent être affectées d'une valeur avant la fin de l'initialiseur, tout comme les références fortes, sinon le compilateur émettra une erreur d'initialisation définitive.
Qu'est-ce qui distingue les règles de délégation pour les initialisateurs de commodité des initialisateurs désignés concernant l'initialisation définitive ?
Les initialisateurs de commodité agissent comme des points d'entrée secondaires qui doivent déléguer à un initialiseur désigné (via self.init) avant d'effectuer toute opération spécifique à l'instance. Ils sont strictement interdits d'initialiser directement des propriétés stockées car l'initialiseur désigné qu'ils appellent porte la responsabilité de satisfaire aux exigences d'initialisation définitive. Cela contraste avec les initialisateurs désignés, qui doivent initialiser toutes les propriétés introduites par leur classe avant de déléguer vers un initialiseur de la superclasse, garantissant que l'objet est valide à chaque niveau de la hiérarchie.