Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロダクト開発でも使おう 関数のオーバーロード
Search
yoiwamoto
June 06, 2025
Programming
0
380
プロダクト開発でも使おう 関数のオーバーロード
yoiwamoto
June 06, 2025
Tweet
Share
More Decks by yoiwamoto
See All by yoiwamoto
標準最高!標準はださくないぞ! at fukuoka.ts #1
yoiwamoto
1
530
Other Decks in Programming
See All in Programming
構文解析器入門
ydah
7
1.9k
Startups on Rails in Past, Present and Future–Irina Nazarova, RailsConf 2025
irinanazarova
0
310
[DevinMeetupTokyo2025] コード書かせないDevinの使い方
takumiyoshikawa
2
220
構造化・自動化・ガードレール - Vibe Coding実践記 -
tonegawa07
0
150
知って得する@cloudflare_vite-pluginのあれこれ
chimame
1
120
副作用と戦う PHP リファクタリング ─ ドメインイベントでビジネスロジックを解きほぐす
kajitack
3
490
[Codecon - 2025] Como não odiar seus testes
camilacampos
0
100
MCPを使ってイベントソーシングのAIコーディングを効率化する / Streamlining Event Sourcing AI Coding with MCP
tomohisa
0
190
AIコーディングエージェント全社導入とセキュリティ対策
hikaruegashira
15
8.5k
Android 16KBページサイズ対応をはじめからていねいに
mine2424
0
770
TypeScriptでDXを上げろ! Hono編
yusukebe
3
880
「次に何を学べばいいか分からない」あなたへ──若手エンジニアのための学習地図
panda_program
3
670
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Faster Mobile Websites
deanohume
308
31k
For a Future-Friendly Web
brad_frost
179
9.8k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.5k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Agile that works and the tools we love
rasmusluckow
329
21k
Into the Great Unknown - MozCon
thekraken
40
1.9k
RailsConf 2023
tenderlove
30
1.2k
Navigating Team Friction
lara
187
15k
Transcript
プロダクト開発でも使おう 関数のオーバーロード Yo Iwamoto プロダクトエンジニア @SmartHR 2025.06.6 TSKaigi 2025 事後勉強会
LT
Yo Iwamoto / 岩元 陽 自己紹介 ❏ SmartHR で勤怠管理機能を作っています ❏
近況: Switch 2 って本当に当たるんですか? @yoiwamoto
None
話したいこと 1. 関数のオーバーロードについて 2. プロダクト開発で役に立った話 3. オーバーロードの性質と使いどころ
Function Overloads
関数のオーバーロード (Function Overload) https://www.typescriptlang.org/docs/handbook/2/functions.html#overload-signatures-and-the-implementation-signature 関数宣言を複数記述するような形式で関数のシグネチャを列挙し、 パターンマッチにより動的にシグネチャを決定させるような機能。
関数のオーバーロード (Function Overload) e.g. react-hook-form の watch() にキー、キーの配列、コールバックが渡せたりするあれ
❏ ライブラリとかでよく使われててなんか便利 ❏ 便利だけど、まあメタプロの類 プロダクト開発で使うかと言われるとあんまり? なイメージ。
うまく使うと実装がとても簡潔になったり 最強関数(いい意味)を作れる素敵な機能なので、 改めて概要 & 使い所を紹介します!
オーバーロードのモチベーション 特に型を工夫しない場合 🤔 引数が string なら string、 number なら number
を返すような関数 → 実際に渡した引数の型から動的に推論さ せることができず、常に `number | string`
Generics で対応してみる 💭 value を T と置いて、返り値型を分岐する (改行の問題ももちろんあるけど、) - 一定、実装が複雑になる。
- as T extends number ? number : string のような as の使用が避けられない オーバーロードのモチベーション
オーバーロードで解決 ✨ 宣言された順の優先度でパターンマッチでシグ ネチャを特定。 実装も型定義もとてもシンプル オーバーロードのモチベーション
要するに、 単一の宣言だと限界がある関数シグネチャを、 分割して宣言することによって容易に表現するめの機能 であって、場合によって単に関数を分割したり、Conditional Type を工夫した り、引数のみの分岐であれば Discriminated Union で表現するなど、
基本的に他の方法が取れる。 → より簡潔な型表現にする / ユーティリティ関数のカバーする ユースケースを増やして便利にするために使う
最近オーバーロードが 役に立った話
作りたかったもの routes 定義のヘルパ。 パスパターンを literal で渡すだけで、必要なパラメータを受け取る path() 関数を返してほしい (こういうものを自前で作ってる経緯は割愛)
実現方法 ざっくりこんな感じで実現できる。 ポイントを分解すると、 ① Template Literal Types ② infer による
literal からの型の抽出 ③ 関数のオーバーロード キモは、パスパラメータを含まないパター ンの route では、引数を渡さなくてもエ ラーにならないこと
よくある使い方 ...は省略
一般化すると
① 引数型を分岐したい場合 → Union がハマらなければ使う! ② 返り値型などを分岐したい場合 → 以下の場合を除いてまず使ってみる! 関数のオーバーロードの使いどき
➢ 同じ関数でカバーできるメリットがないかも ➢ Template Literal Types などでパターン量が爆発するかも
引数にパターンがあるだけであれば、理論上ただの Union でほぼ表現できる。 が、Positional Argument の構造が分岐できない! ⚠ 使いどき ① 引数型を分岐したい場合
公式のサンプルコードでは Positional Argument の構造が分岐していて、 makeDate(1749198911) とも呼べるし、 makeDate(6, 6, 2025) とも呼べる
これは Union の場合、以下のようにオブジェクト形式にする、あるいは第二引数を optional にするなどでしか実現できない。 使いどき ① 引数型を分岐したい場合
最初の例で言うと、 PathParameter が `{}` であるような場合に第一引数を required にしたり optional にしたりできているのはオーバーロードのおかげ。 使いどき
① 引数型を分岐したい場合
使いどき ② 返り値型などを分岐したい場合 基本的には使える が、なんでもありのオーバーロードは正直全く関係のない関数もまとめられるもので、 (理論上は)アプリケーションの全ての関数を 1つでカバーできたりする 秩序を保つために、以下は考える - 同じ関数であるメリットがあるか?
- Template Literal Types などでパターン数が爆発しないか? - 推論の度に動的にパターンマッチが実行される - 極端にパターンの多い計算を含んでいると、通常の関数定義より負荷がかかる
おわり