În exemplul de mai sus, în ciuda adăugării funcției de inițializare, am eliminat necesitatea multor declarații verboase „if-let” și „guard-else” în timpul analizei codului (necesare doar atunci când gestionăm întoarcerea opțională de la crearea unui URL). În plus, observați că proprietatea id obișnuită, neopțională, și proprietatea opțională caption sunt analizate folosind aceeași sintaxă de cod. Primul parametru al funcției de decodare pentru caption specifică faptul că se așteaptă la o valoare opțională prin adăugarea unui semn de întrebare după tipul de date așteptat.

În acest moment, codul nostru de parsare se apropie de lungimea obiectului original necodabil. Cu toate acestea, noul cod este mai clar și separă zonele de cod în care se fac în mod obișnuit greșeli de scriere (șirurile care specifică cheile JSON) într-un enum ușor de identificat.

Prin separarea cheilor JSON într-un enum și eliminarea necesității majorității instrucțiunilor „if-let” și „guard-else”, protocolul Codable prezentat mai sus ne oferă un spațiu amplu pentru a dezvolta obiectele noastre fără a crește drastic complexitatea codului.

În general, persoanele sau echipele care își gestionează atât codul back-end, cât și cel front-end au libertatea de a-și ajusta în mod continuu modelul de date pentru a lucra cu modelele lor vizuale, cu o logistică redusă (dacă nu ați fost niciodată la o întâlnire între dezvoltatori front-end și back-end la fel de încăpățânați, considerați-vă norocoși). Pentru cei care se încadrează în această categorie, beneficiile implementării Codable sunt de a avea obiecte Swift declarate și analizate cu cea mai mică cantitate de cod posibilă și de a ține pasul cu cele mai bune practici și așteptări ale Apple. Cu toate acestea, dacă faceți parte dintr-o echipă de dezvoltare la scară largă care se ocupă de API-uri furnizate de o entitate separată, în care nu puteți controla momentul sau detaliile schimbărilor în datele pe care vă așteptați să fie returnate, Codable ar putea fi farul vostru strălucitor de speranță în mijlocul nebuniei.

Imaginați-vă că efectuați trei apeluri API în diferite zone ale unei aplicații, în care fiecare ar trebui să returneze exact același obiect Swift. În acest API nefericit, se întâmplă ca fiecare dintre aceste apeluri să returneze date cu o cheie de dicționar ușor diferită; object_id, obj_id și Object_ID, toate cu intenția de a se referi la aceeași proprietate, objectId, de pe obiectul pe care intenționați să îl creați. Anterior, o funcție de decodare ar fi trebuit să aibă o serie de declarații „if-let” pentru a verifica id-ul în fiecare dintre aceste chei înainte de a decide în cele din urmă ce valoare, dacă există, să seteze ca proprietate.

.