TypeScriptのIntersection Typesで「疎結合な責務」を合成し、型安全なコンポーネントを設計する
多くのエンジニアが「TypeScriptの型定義」を単なるデータ構造の記述だと思っている。だが、真のフロントエンドアーキテクトにとって、型定義とは「コードの設計図そのもの」であり、コンパイラの静的解析能力を最大限に引き出すための武器だ。
今回は、関数の引数に `Intersection Types (&)` を用いて複数の責務を合成する、実務直結の設計パターンを伝授する。なぜただの `interface` の継承では不十分なのか、なぜこの手法がプロダクションコードを「壊れないもの」に変えるのかを解説しよう。
—
なぜ「継承」ではなく「合成」を選ぶべきなのか
インターフェースの継承（`extends`）は、しばしば「深い階層構造」を生む。これはオブジェクト指向の悪癖であり、コンポーネント設計においては「不要なプロパティまで引き継ぐ」という最大の負債を招く。
対して、`Intersection Types (&)` を用いた合成は、責務の切り出しだ。
「認証情報が必要な関数」と「ログ出力が必要な関数」を個別に定義し、必要な場面でそれらをマージする。このアプローチは「単一責任の原則（SRP）」を型レベルで強制する。
—
実践：疎結合な責務の合成パターン
例えば、API通信を行う関数を考えてみる。この関数には「認証トークン」と「リクエストボディ」という2つの独立した責務がある。
// 責務1: 認証情報
interface AuthContext {
token: string;
userId: string;
}
// 責務2: APIリクエストのペイロード
interface UserProfilePayload {
username: string;
bio: string;
}
/
- 責務を合成した関数シグネチャ
- 呼び出し側は、AuthContext と UserProfilePayload を満たすオブジェクトを渡す必要がある
/
function updateProfile(params: AuthContext & UserProfilePayload) {
const { token, username, bio } = params;
console.log(`Updating profile for ${username} with token: ${token.slice(0, 5)}…`);
// 実際の fetch 処理
}
// 使用例
updateProfile({
token: “abc-123-xyz”,
userId: “user_001”,
username: “TypeScriptWizard”,
bio: “Architecting the future.”
});
この設計が優れている理由
1. 高い再利用性: `AuthContext` だけを別の関数（例：`deleteAccount`）で再利用できる。
2. 型推論の正確性: `params` 内のプロパティは、コンパイル時にすべて解決され、エディタの補完が完璧に効く。
3. 副作用の局所化: どの引数がどの責務に由来するかが明確になり、コードレビューで「なぜこの関数にこの権限が必要なのか？」という問いが即座に生まれる。
—
パフォーマンスとコンパイラの重み
ここで一つ、シニアレベルの注意点を共有する。`Intersection Types` を過剰にネストさせたり、複雑な計算を伴う型（Mapped Typesなど）と組み合わせすぎると、TypeScriptの型チェック（`tsc`）のパフォーマンスは劇的に低下する。
- 型推論の停止を防ぐ: `&` で結合する際、巨大なオブジェクトを何層にも重ねることは避けよ。
- 名前付き型を優先する: `type Merged = A & B & C` のように、名前を付けることで、エディタ上のホバー時に TypeScript のエンジンが型を簡略化して表示してくれる。
—
現場で差がつく「オプショナル引数」との組み合わせ
実務では、すべてのデータが揃っているとは限らない。`Partial` を組み合わせることで、より柔軟なAPI設計が可能になる。
// 責務の合成と、更新時の「一部更新」の共存
type UpdateParams = AuthContext & Partial
function patchProfile(params: UpdateParams) {
// token は必須だが、bio だけ更新することも可能
if (params.bio) {
console.log(“Updating bio…”);
}
}
このパターンを使えば、「必須の認証情報」と「柔軟なデータ更新」を1つの型で完璧に表現できる。 `any` や `Partial
—
結論：型はドキュメントであり、契約である
コードを書く際、引数の型定義を見て「あ、この関数はこのデータとこのデータに依存しているんだな」と一瞬で理解できる状態を作ること。それが、大規模開発におけるリードエンジニアの役割だ。
`&` を使った型合成は、単なる機能ではない。それは「責務を分解し、再結合する」というアーキテクチャの意思表示である。今日から継承による結合を止め、合成による疎結合な型設計を実践してほしい。
TypeScriptの型システムは、あなたが思っている以上に賢い。そのポテンシャルを使いこなせば、実行時のバグは劇的に減る。さあ、型を武器に、堅牢なプロダクトを構築しよう。