I eksemplet ovenfor har vi på trods af tilføjelsen af initialiseringsfunktionen elimineret behovet for mange mundrette “if-let” og “guard-else” udsagn, mens vi analyserer koden (kun nødvendigt, når vi håndterer den valgfrie returnering fra oprettelsen af en URL). Bemærk desuden, at den almindelige, ikke-valgfri id-egenskab og den valgfrie caption-egenskab analyseres ved hjælp af den samme kodesyntaks. Den første parameter i decode-funktionen for caption angiver, at den forventer en valgfri værdi ved at tilføje et spørgsmålstegn efter den forventede datatype.

På dette tidspunkt nærmer vores parsing-kode sig længden af det oprindelige non-Codable-objekt. Den nye kode er imidlertid mere overskuelig og adskiller de områder af koden, hvor der ofte sker tastefejl (de strenge, der angiver JSON-nøgler), i et let identificerbart enum.

Da vi adskiller JSON-nøglerne i et enum og eliminerer behovet for de fleste “if-let”- og “guard-else”-sætninger, giver den ovenfor viste Codable-protokol os rigelig plads til at bygge videre på vores objekter uden drastisk at øge kodens kompleksitet.

Individer eller teams, der administrerer både deres back-end og front-end kode, har generelt frihed til løbende at justere deres datamodel, så den fungerer sammen med deres visuelle modeller, med lidt overhead logistik (hvis du aldrig har været til et møde mellem lige stædige front-end og back-end udviklere, så regn dig selv for heldig). For dem, der falder ind under denne kategori, er fordelene ved at implementere Codable at få Swift-objekter erklæret og analyseret med den mindst mulige mængde kode og at holde trit med Apples bedste praksis og forventninger. Men hvis du er på et stort udviklingsteam, der beskæftiger sig med API’er, der leveres af en separat enhed, hvor du ikke kan kontrollere timingen eller detaljerne i ændringer i de data, du forventer at få returneret, kan Codable være dit lysende håb midt i galskaben.

Forestil dig, at du foretager tre API-kald i forskellige områder af et program, hvor det er meningen, at de hver især skal returnere nøjagtig det samme Swift-objekt. I dette uheldige API-kald returnerer hvert af disse kald tilfældigvis data med en lidt forskellig ordbogsnøgle; object_id, obj_id og Object_ID, der alle har til hensigt at henvise til den samme egenskab, objectId, på det objekt, du har til hensigt at oprette. Tidligere skulle en afkodningsfunktion have en række “if-let”-sætninger for at kontrollere id’et i hver af disse nøgler, før den i sidste ende besluttede, hvilken værdi, hvis nogen, der skulle sættes som egenskab.