No exemplo acima, apesar de adicionar a função de inicialização, eliminamos a necessidade de muitas declarações verbosas “if-let” e “guard-else” enquanto analisamos o código (apenas necessário quando se trata do retorno opcional da criação de uma URL). Além disso, observe que a propriedade regular, não-opcional, id e a propriedade opcional caption são interpretadas usando a mesma sintaxe de código. O primeiro parâmetro da função de decodificação para o título especifica que ele espera um valor opcional, anexando um ponto de interrogação após o tipo de dado esperado.

Neste ponto, nosso código de análise está próximo do comprimento do objeto original não-codificável. Contudo, o novo código é mais claro e separa as áreas do código onde os erros de digitação são normalmente feitos (as strings especificando as chaves JSON) em um enumero facilmente identificável.

Separando as chaves JSON em um enumero e eliminando a necessidade da maioria das declarações “if-let” e “guard-else”, o protocolo Codable mostrado acima nos dá amplo espaço para construir sobre nossos objetos sem aumentar drasticamente a complexidade do código.

Indivíduos ou equipes que gerenciam tanto o código back-end quanto o front-end geralmente têm a liberdade de ajustar continuamente seu modelo de dados para trabalhar com seus modelos visuais, com pouca sobrecarga logística (se você nunca esteve em uma reunião entre desenvolvedores igualmente teimosos front-end e back-end, considere-se sortudo). Para aqueles que se enquadram nessa categoria, os benefícios de implementar o Codable são ter objetos Swift declarados e analisados com a menor quantidade possível de código e acompanhar as melhores práticas e expectativas da Apple. Entretanto, se você está em uma equipe de desenvolvimento em larga escala lidando com APIs fornecidas por uma entidade separada, onde você não pode controlar o tempo ou os detalhes das mudanças nos dados que você espera que sejam retornados, o Codable pode ser seu farol brilhante de esperança em meio à loucura.

Imagine fazer três chamadas API em áreas diferentes de uma aplicação, onde cada uma deve retornar exatamente o mesmo objeto Swift. Nessa infeliz API, cada uma dessas chamadas retorna dados com uma chave de dicionário ligeiramente diferente; object_id, obj_id, e Object_ID, todas com a intenção de se referir à mesma propriedade, objectId, no objeto que você pretende criar. Anteriormente, uma função de decodificação precisaria ter uma série de instruções “if-let” para verificar o id em cada uma dessas chaves antes de finalmente decidir qual, se houver, o valor a ser definido como a propriedade.