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
140
プロダクト開発でも使おう 関数のオーバーロード
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
Parallel::Pipesの紹介
skaji
2
910
💎 My RubyKaigi Effect in 2025: Top Ruby Companies 🌐
yasulab
PRO
1
130
JSAI2025 RecSysChallenge2024 優勝報告
unonao
1
450
Cline指示通りに動かない? AI小説エージェントで学ぶ指示書の書き方と自動アップデートの仕組み
kamomeashizawa
1
430
実践ArchUnit ~実例による検証パターンの紹介~
ogiwarat
2
250
Datadog RUM 本番導入までの道
shinter61
1
250
RubyKaigiで得られる10の価値 〜Ruby話を聞くことだけが RubyKaigiじゃない〜
tomohiko9090
0
140
事業戦略を理解してソフトウェアを設計する
masuda220
PRO
21
5.9k
統一感のある Go コードを生成 AI の力で手にいれる
otakakot
0
2.9k
コードに語らせよう――自己ドキュメント化が内包する楽しさについて / Let the Code Speak
nrslib
6
1.4k
CSC307 Lecture 17
javiergs
PRO
0
110
Enterprise Web App. Development (2): Version Control Tool Training Ver. 5.1
knakagawa
1
110
Featured
See All Featured
How to Ace a Technical Interview
jacobian
276
23k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
480
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
900
Building a Modern Day E-commerce SEO Strategy
aleyda
41
7.3k
Building Applications with DynamoDB
mza
95
6.4k
Raft: Consensus for Rubyists
vanstee
139
7k
Gamification - CAS2011
davidbonilla
81
5.3k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Into the Great Unknown - MozCon
thekraken
39
1.8k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
43
2.4k
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 などでパターン数が爆発しないか? - 推論の度に動的にパターンマッチが実行される - 極端にパターンの多い計算を含んでいると、通常の関数定義より負荷がかかる
おわり