Nell’esempio sopra, nonostante l’aggiunta della funzione di inizializzazione, abbiamo eliminato la necessità di molte verbose dichiarazioni “if-let” e “guard-else” durante l’analisi del codice (necessarie solo quando si gestisce il ritorno opzionale dalla creazione di un URL). Inoltre, si noti che la proprietà id regolare, non opzionale, e la proprietà opzionale caption sono analizzate usando la stessa sintassi del codice. Il primo parametro della funzione di decodifica per la didascalia specifica che si aspetta un valore opzionale aggiungendo un punto interrogativo dopo il tipo di dati previsto.

A questo punto, il nostro codice di analisi si avvicina alla lunghezza dell’oggetto originale non codificabile. Tuttavia, il nuovo codice è più chiaro e separa le aree del codice dove gli errori di battitura sono comuni (le stringhe che specificano le chiavi JSON) in un enum facilmente identificabile.

Separando le chiavi JSON in un enum ed eliminando la necessità di molte dichiarazioni “if-let” e “guard-else”, il protocollo Codable mostrato sopra ci dà ampio spazio per costruire sui nostri oggetti senza aumentare drasticamente la complessità del codice.

Gli individui o i team che gestiscono sia il loro codice back-end che front-end hanno generalmente la libertà di adattare continuamente il loro modello di dati per lavorare con i loro modelli visivi, con poca logistica overhead (se non siete mai stati ad una riunione tra sviluppatori front-end e back-end ugualmente testardi, ritenetevi fortunati). Per coloro che rientrano in questa categoria, i benefici dell’implementazione di Codable sono di avere oggetti Swift dichiarati e analizzati con la minor quantità di codice possibile e di stare al passo con le migliori pratiche e aspettative di Apple. Tuttavia, se siete in un team di sviluppo su larga scala che ha a che fare con API fornite da un’entità separata, dove non potete controllare i tempi o i dettagli dei cambiamenti nei dati che vi aspettate vengano restituiti, Codable potrebbe essere il vostro luminoso faro di speranza in mezzo alla follia.

Immaginate di fare tre chiamate API in diverse aree di un’applicazione, dove ognuna dovrebbe restituire lo stesso esatto oggetto Swift. In questa sfortunata API, ognuna di queste chiamate restituisce dati con una chiave di dizionario leggermente diversa; object_id, obj_id, e Object_ID, tutte intenzionate a riferirsi alla stessa proprietà, objectId, sull’oggetto che si vuole creare. In precedenza, una funzione di decodifica avrebbe dovuto avere una serie di dichiarazioni “if-let” per controllare l’id in ciascuna di queste chiavi prima di decidere alla fine quale, se c’è, valore impostare come proprietà.