Dans l’exemple ci-dessus, malgré l’ajout de la fonction d’initialisation, nous avons éliminé le besoin de nombreuses déclarations verbeuses « if-let » et « guard-else » lors de l’analyse du code (uniquement nécessaire lors de la gestion du retour optionnel de la création d’une URL). De plus, remarquez que la propriété id régulière, non optionnelle, et la propriété caption optionnelle sont analysées en utilisant la même syntaxe de code. Le premier paramètre de la fonction de décodage de la légende précise qu’elle attend une valeur facultative en ajoutant un point d’interrogation après le type de données attendu.
À ce stade, notre code d’analyse syntaxique approche de la longueur de l’objet original non codable. Cependant, le nouveau code est plus clair et sépare les zones du code où les erreurs de frappe sont couramment commises (les chaînes spécifiant les clés JSON) en une énumération facilement identifiable.
En séparant les clés JSON en une énumération et en éliminant le besoin de la plupart des déclarations « if-let » et « guard-else », le protocole Codable présenté ci-dessus nous donne amplement de place pour construire sur nos objets sans augmenter drastiquement la complexité du code.
Les individus ou les équipes qui gèrent à la fois leur code back-end et front-end ont généralement la liberté d’ajuster continuellement leur modèle de données pour travailler avec leurs modèles visuels, avec peu de logistique de frais généraux (si vous n’avez jamais assisté à une réunion entre des développeurs front-end et back-end également têtus, estimez-vous heureux). Pour ceux qui appartiennent à cette catégorie, les avantages de l’implémentation de Codable sont d’avoir des objets Swift déclarés et analysés avec le moins de code possible et de rester en phase avec les meilleures pratiques et attentes d’Apple. Cependant, si vous faites partie d’une équipe de développement à grande échelle qui traite des API fournies par une entité distincte, où vous ne pouvez pas contrôler le calendrier ou les détails des changements dans les données que vous attendez d’être retournées, Codable pourrait être votre lueur d’espoir au milieu de la folie.
Imaginez faire trois appels d’API dans différentes zones d’une application, où chacun est censé retourner exactement le même objet Swift. Dans cette malheureuse API, chacun de ces appels se trouve à renvoyer des données avec une clé de dictionnaire légèrement différente ; object_id, obj_id et Object_ID, tous ayant l’intention de se référer à la même propriété, objectId, sur l’objet que vous visez à créer. Auparavant, une fonction de décodage devait avoir une série d’instructions « if-let » pour vérifier l’id dans chacune de ces clés avant de décider finalement quelle valeur, s’il y en a une, définir comme propriété.