In het bovenstaande voorbeeld hebben we, ondanks het toevoegen van de initialisatiefunctie, de noodzaak van vele verbbose “if-let” en “guard-else” statements tijdens het parseren van de code geëlimineerd (alleen nodig bij het afhandelen van de optionele terugkeer van het maken van een URL). Merk ook op dat de gewone, niet-optionele, id eigenschap, en de optionele caption eigenschap worden geparseerd met behulp van dezelfde code syntaxis. De eerste parameter van de decodeerfunctie voor het bijschrift specificeert dat het een optionele waarde verwacht door een vraagteken toe te voegen na het verwachte gegevenstype.

Op dit punt nadert onze parseercode de lengte van het oorspronkelijke niet-Codeerbare object. De nieuwe code is echter duidelijker en scheidt de delen van de code waar vaak typefouten worden gemaakt (de strings die JSON-sleutels specificeren) in een gemakkelijk identificeerbaar enum.

Door de JSON-sleutels in een enum te scheiden en de noodzaak van de meeste “if-let” en “guard-else” verklaringen te elimineren, geeft het hierboven getoonde Codable-protocol ons voldoende ruimte om op onze objecten voort te bouwen zonder de complexiteit van de code drastisch te vergroten.

Individuen of teams die zowel hun back-end als front-end code beheren, hebben over het algemeen de vrijheid om hun gegevensmodel voortdurend aan te passen aan hun visuele modellen, met weinig overhead logistiek (als je nog nooit naar een vergadering bent geweest tussen even koppige front-end en back-end ontwikkelaars, prijs jezelf dan gelukkig). Voor degenen die in die categorie vallen, zijn de voordelen van het implementeren van Codable dat Swift-objecten worden gedeclareerd en geparsed met de kleinst mogelijke hoeveelheid code en dat je meegaat met de best practices en verwachtingen van Apple. Als je echter in een groot ontwikkelteam zit dat te maken heeft met API’s die worden geleverd door een aparte entiteit, waarbij je geen controle hebt over de timing of details van wijzigingen in de gegevens die je verwacht terug te krijgen, kan Codable je lichtend baken van hoop zijn temidden van de waanzin.

Stel je voor dat je drie API-aanroepen doet in verschillende delen van een applicatie, waarbij elke aanroep geacht wordt exact hetzelfde Swift-object terug te geven. In deze ongelukkige API retourneert elk van deze aanroepen gegevens met een iets andere woordenboeksleutel; object_id, obj_id, en Object_ID, die allemaal moeten verwijzen naar dezelfde eigenschap, objectId, op het object dat je wilt maken. Voorheen moest een decoderingsfunctie een reeks “if-let” verklaringen hebben om te controleren op de id in elk van die sleutels alvorens uiteindelijk te beslissen welke, indien aanwezig, waarde moest worden ingesteld als de eigenschap.