Goの好きなとこと嫌いなとこ
asRagi.icon好きなとこ
UserId型へのメソッドはどんどん生やしていける 三項演算子の排除など，不要な機能を安易に採用しない姿勢に共感を持てる． その分即時関数とかは用意されていて，この辺りの気持ちも共感がある． code:.go
// 三項演算子が（もしあったら）こんな感じ
userId := userResponse != nil ? userResponse.UserId : ""
// 即時関数を用いてこう書くと記述量はめちゃくちゃ増えるが，フローや意図は明確になり，拡張性もしっかりある．
userId := func(response UserResponse) UserId {
if response == nil {
return ""
}
return response.UserId
}(userResponse)
asRagi.icon嫌いなとこ
code:.go
type UserRequest struct {
UserId UserId
Body RequestBody
}
type AgentRequest struct {
AgentId AgentId
Body AgentBody
}
type RequestInterface interface{}
// UserやAgentからのRequestをどちらもリスト的に処理していきたい
var requests []RequestInterface
requests := BatchGetRequest() // このとき，RequestInterfaceはinterface{}なので異常な型が入る場合がある
for _, req := range requests {
switch r := req.(type) { // 型Switch
case UserRequest:
// なんらかの処理
case AgentRequest:
// ......
}
}
code:.cs
class UserRequest: IRequest {
public UserId UserId { get; }
public RequestBody Body { get; }
}
class AgentRequest: IRequest {
public AgentId AgentId { get; }
public AgentBody Body { get; }
}
interface IRequest {}
IRequest[] requests = BatchGetRequest(); // IRequestを実装していないクラスは絶対に紛れ込まない
C#だと接頭辞としてIObserverのようにIがつくため一目瞭然だが，Goではそういう命名規則がない（徹底されていない）ため，命名が難しい． 一応Senderみたいな-erの接尾辞が推奨されているらしい？ coreみたいなmoduleでUserに対する計算処理の関数を生やしたとき，それがUser以外のcore内から常に見えるのはアクセスレベルが大きくない？ じゃあUserPasswordMessageみたいにそれぞれの（C#でいうクラスの単位で）moduleを生やすのかというとそうではない 配列に対する操作をスマートに書く手段が提供されていない