9日目、サーバーサイドエンジニアの星井です。元プロレスラーのベネズエラ人とスパーリングをしていて、投稿が遅くなりました。Interfaceの条件分岐の書き方で迷うことが多いので、今日はどの書き方が良いかを考察してみようと思います。どんな書き方ができるかInterfaceの種類別に異なる処理をしたい時、下記のようにtypeごとにSwitchで条件分岐するのが一般的ではないでしょうか。}メリットは分岐しながら元の型に戻せるところで、デメリットは分岐が多くなると可読性が下がってしまうところです。2Typeを使ったSwitch分岐それぞれの構造体にTypeという判別用のフィールドを持たせ、Type()という関数を呼んで条件分岐する書き方もできます。}こちらはあまりメリットが思いつかない。デメリットは下記です。最後にmapを使った書き方ができます。},}分岐と関数を分けて書けるため、分岐が増えても関数自体の長さを減らすことができ、読みやすいのがメリットです。2と同じで、構造体を生成する時に、必ず正しいTypeをセットしなければいけないのがデメリットですね。どの書き方が一番速いのかこれらの書き方で一番速そうなのは「1スタンダードなSwitch分岐」かなと予想しました。ある記事によると、単純な条件分岐だとSwitchよりMapが速いそうで、実はMapが速いとなったら面白いなと思って、自分で実験してみることにしました。50000個のランダムな値で実行した時のベンチマークがこちらです。ns/op順番的には1>2>3だったので、きっとType()を呼ぶのに時間がかかるのでしょう。単純な条件分岐だとSwitchよりMapが速い説もここでは使えなかったのは、Mapにした場合、別で関数を呼んで実行しなければいけなかったからですかね。一部ランダムな値で実行時に2>1になったりしているので、条件分岐の数を増やしたりするともしかしたら全然違う結果になるかもしれません。まとめメリットとデメリットを表にまとめました。基本的には一般的なSwitch分岐が良いと思います。処理速度に優位があると言ってもナノ秒の世界ですし、可読性の観点からMapの分岐を選択するのも良さそうです。・構造体を生成する時に必ず正しいTypeを指定しなければいけない・Switchに比べて処理に時間がかかる本当は正解をパッと決めたかったのですが、残念ながら処理速度と可読性のバランスを考えて実装しましょうという無難でつまらない結論になりました。q...2021-06-14OpenAPIスキーマ駆動開発におけるoapi-codegenを用いたリクエストバリデーションこんにちは、バックエンドエンジニアの鈴木(善)です。sliceとmapどっちが速いのだね?こんにちは。サーバサイドエンジニアの藤原です。Award受賞の裏側:GitHub通知の最適活用法エンジニア積極採用中!会社概要HRBrainとはお問い合わせ引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。