あとおもちさんのHasDecodableProxyは他にも（あるいは他じゃないのかもしれないけど）引っかかるところがあって、 3層レイヤードアーキテクチャ View - Model - Infra 層があったとして、 CodableProxyはInfra層のDTO HasDecodableProxyはModel層のDomainObject になると思っていいかなそうすると、 1. 依存の方向を Model <- Infra にしたいけど、HasDecodableProxyの構造だとそれができない 2. CodableProxyがひとつに固定されてしまうという問題がある

依存の方向を Model <- Infra にしたいけど、HasDecodableProxyの構造だとそれができない

雑に言えばmemberwise initializerがinternalになるのと同種の問題だと思ってよくて、 DTOをInfra層に閉じ込めようとするとHasDecodableProxyをInfra側にextensionで書くことになるそうするとDomainObjectのpublic memberwise initializerを手で書かにゃならん DomainObjectにプロパティがたくさんあった場合、

public memberwise initializer
init(fromCodableProxy proxy: CodableProxy)

を手作業で書きまくって、それぞれをメンテしなきゃいけないの気が遠くなりそう

CodableProxyがひとつに固定されてしまう

明確な問題はたとえばCatを取得したくて、 V1 APIとV2 APIでレスポンス構造が変わるけどどちらもクライアントでは同じCatとして扱いたいそうすると以下のようになると思うんだけど

CatDTOV1: { id: Int, name: String, ownerID: Int, ownerName: String, ... } CatDTOV2: { id: Int, name: String, owner: Owner, ... }

struct Cat: HasDecodableProxy { typealias CodableProxy = CatDTOV1??CatDTOV2?? } このときassoctypeとしてProxyはV1かV2かどっちかひとつに固定されるのはきつくない？ (edited)