En el ejemplo anterior, a pesar de añadir la función de inicialización, hemos eliminado la necesidad de muchas declaraciones verbosas «if-let» y «guard-else» mientras se analiza el código (sólo necesario cuando se maneja el retorno opcional de la creación de una URL). Además, observe que la propiedad regular, no opcional, id, y la propiedad opcional caption se analizan utilizando la misma sintaxis de código. El primer parámetro de la función de decodificación para el título especifica que espera un valor opcional añadiendo un signo de interrogación después del tipo de datos esperado.
En este punto, nuestro código de análisis se acerca a la longitud del objeto original no codificable. Sin embargo, el nuevo código es más claro y separa las áreas del código en las que se suelen cometer errores tipográficos (las cadenas que especifican las claves JSON) en un enum fácilmente identificable.
Al separar las claves JSON en un enum y eliminar la necesidad de la mayoría de las sentencias «if-let» y «guard-else», el protocolo Codable mostrado anteriormente nos da un amplio espacio para construir sobre nuestros objetos sin aumentar drásticamente la complejidad del código.
Las personas o equipos que gestionan tanto su código de back-end como de front-end generalmente tienen la libertad de ajustar continuamente su modelo de datos para trabajar con sus modelos visuales, con poca logística de sobrecarga (si nunca has estado en una reunión entre desarrolladores de front-end y back-end igualmente obstinados, considérate afortunado). Para aquellos que entran en esa categoría, los beneficios de implementar Codable son tener objetos Swift declarados y analizados con la menor cantidad de código posible y mantenerse al día con las mejores prácticas y expectativas de Apple. Sin embargo, si estás en un equipo de desarrollo a gran escala tratando con APIs proporcionadas por una entidad independiente, donde no puedes controlar el tiempo o los detalles de los cambios en los datos que esperas que sean devueltos, Codable podría ser tu faro brillante de esperanza en medio de la locura.
Imagina hacer tres llamadas a la API en diferentes áreas de una aplicación, donde cada una se supone que debe devolver exactamente el mismo objeto Swift. En esta desafortunada API, cada una de esas llamadas resulta que devuelve datos con una clave de diccionario ligeramente diferente; object_id, obj_id, y Object_ID, todas con la intención de referirse a la misma propiedad, objectId, en el objeto que se pretende crear. Anteriormente, una función de decodificación tendría que tener una serie de sentencias «if-let» para comprobar el id en cada una de esas claves antes de decidir finalmente qué valor, si es que hay alguno, establecer como propiedad.