上の例では、初期化関数を追加したにもかかわらず、コードを解析している間、多くの冗長な「if-let」と「guard-else」文が不要になりました (URL 作成から戻るオプション品を扱うときだけ必要です)。 さらに、通常の、オプションではない id プロパティと、オプションの caption プロパティが、同じコード構文で解析されることに注目してください。 caption のデコード関数の最初のパラメーターは、予想されるデータ型の後にクエスチョンマークを追加することにより、オプションの値を期待することを指定します。

この時点で、解析コードは元の非コード可能オブジェクトの長さに近くなっています。 しかし、新しいコードはより明確で、タイプミスがよく起こるコードの領域 (JSON キーを指定する文字列) を簡単に識別できる列挙型に分離します。

JSON キーを列挙型に分離して、ほとんどの “if-let” および “guard-else” 文を不要にすることにより、上に示した Codable プロトコルはコードの複雑さを劇的に増加させずにオブジェクトに構築できる十分なスペースを提供します。

バックエンドとフロントエンドの両方のコードを管理する個人またはチームは、一般に、ほとんどオーバーヘッドの物流なしで、ビジュアル モデルと連携するようにデータ モデルを継続的に調整する自由があります (同様に頑固なフロントエンドおよびバックエンド開発者のミーティングに行ったことがない場合、ラッキーだと思いましょう)。 そのようなカテゴリに分類される人々にとって、Codable を実装する利点は、可能な限り少ないコード量で Swift オブジェクトを宣言し解析させることと、Apple のベストプラクティスと期待に追いつくことです。 しかし、もしあなたが、返されることを期待するデータの変更のタイミングまたは詳細を制御できない、別のエンティティによって提供される API を扱う大規模な開発チームであるなら、Codable は狂気の中で輝く希望の光になるかもしれません。 この不幸な API では、これらの呼び出しのそれぞれが、わずかに異なる辞書キーでデータを返すことが起こります; object_id、obj_id、および Object_ID、すべては、あなたが作成することを目的とするオブジェクト上の同じプロパティ、objectId を参照することを意図しています。 以前は、デコード関数は、最終的にプロパティとして設定する値を決定する前に、これらのキーの id をチェックする一連の “if-let” ステートメントを持つ必要がありました。