I exemplet ovan har vi, trots att vi har lagt till initialiseringsfunktionen, eliminerat behovet av många verbala ”if-let” och ”guard-else” uttalanden när vi analyserar koden (endast nödvändigt när vi hanterar den valfria returen från skapandet av en URL). Lägg dessutom märke till att den vanliga, icke-frivilliga id-egenskapen och den frivilliga caption-egenskapen analyseras med hjälp av samma kodsyntax. Den första parametern i avkodningsfunktionen för caption anger att den förväntar sig ett valfritt värde genom att lägga till ett frågetecken efter den förväntade datatypen.

I det här läget närmar sig vår analyseringskod längden på det ursprungliga icke-kodningsbara objektet. Den nya koden är dock tydligare och separerar de delar av koden där det ofta görs felskrivningar (de strängar som specificerar JSON-nycklar) till ett lätt identifierbart enum.

Då JSON-nycklarna separeras till ett enum och behovet av de flesta ”if-let”- och ”guard-else”-satser elimineras, ger Codable-protokollet som visas ovan oss gott om utrymme för att bygga vidare på våra objekt utan att koden blir drastiskt mer komplicerad.

Individer eller team som hanterar både sin back-end- och front-end-kod har i allmänhet friheten att kontinuerligt justera sin datamodell så att den fungerar tillsammans med deras visuella modeller, med liten logistik för omkostnader (om du aldrig har varit med om ett möte mellan lika envisa front-end- och back-end-utvecklare ska du skatta dig lycklig). För dem som hör till den kategorin är fördelarna med att implementera Codable att Swift-objekten deklareras och analyseras med så lite kod som möjligt och att hålla jämna steg med Apples bästa praxis och förväntningar. Men om du ingår i ett storskaligt utvecklingsteam som arbetar med API:er som tillhandahålls av en separat enhet, där du inte kan styra tidpunkten eller detaljerna för förändringar i de data som du förväntar dig att få tillbaka, kan Codable vara din lysande ledstjärna av hopp mitt i vansinnet.

Föreställ dig att du gör tre API-anrop i olika delar av en applikation, där varje anrop är tänkt att returnera exakt samma Swift-objekt. I det här olyckliga API:et råkar vart och ett av dessa anrop returnera data med en något annorlunda ordboksnyckel; object_id, obj_id och Object_ID, som alla syftar till att hänvisa till samma egenskap, objectId, på det objekt som du vill skapa. Tidigare behövde en avkodningsfunktion ha en rad ”if-let”-instruktioner för att kontrollera id i var och en av dessa nycklar innan den slutligen bestämde sig för vilket värde, om något, som skulle sättas som egenskap.