TypeScriptの深淵：継承の呪縛を解き、コンポジションで型を再定義する
多くのエンジニアが「オブジェクト指向の延長」として `interface` の `extends` を多用する。しかし、TypeScriptの型システムは本質的に「構造的部分型（Structural Subtyping）」であり、`extends` は単なる継承の糖衣構文に過ぎない。
大規模なアーキテクチャにおいて、安易な継承は「型定義の硬直化」を招き、コンパイラ（`tsc`）のパフォーマンスを低下させ、挙動の予測可能性を奪う。本稿では、継承という名の鎖を断ち切り、コンポジション（合成）によって型を再構築する「真の型設計」について、コンパイラの内部挙動を交えて解説する。
—
1. 継承がもたらす「型評価」の遅延と複雑性の増大
TypeScriptのコンパイラは、型を解決する際に「型関係（Type Relationships）」を探索する。`interface A extends B` を定義した瞬間、コンパイラは `A` が `B` のプロパティをすべて保持しているかを確認し、内部的にキャッシュを生成する。
問題は、深くネストされた継承ツリーだ。継承が深くなればなるほど、コンパイラの「型整合性チェック」のパスは指数関数的に増加し、IDEのレスポンスやビルド時間に悪影響を与える。
継承の悪例：脆い階層構造
interface BaseEntity { id: string; createdAt: Date; }
interface User extends BaseEntity { name: string; }
interface Admin extends User { permissions: string[]; }
この構造は、`Admin` 型を変更した際に `BaseEntity` にまで影響が波及する可能性がある。特に大規模なリファクタリング時、この「密結合」は破壊的な変更を誘発する。
—
2. コンポジションへの回帰：Intersection Typesによる「型パーツ」の再利用
コンポジションの極意は、「型をオブジェクトのプロパティの集合体として定義し、それらを交差（Intersection）させること」にある。
`interface` を用いた継承ではなく、`type` エイリアスと `&`（Intersection）を主軸に据えることで、型定義は「階層」から「フラットなカタログ」へと変貌する。
// コンポーネント指向の型パーツ
type Identity = { id: string };
type Timestamp = { createdAt: Date; updatedAt: Date };
type UserProfile = { name: string; email: string };
// 合成による型構築
type User = Identity & Timestamp & UserProfile;
// 特殊な権限を持つオブジェクトも、合成で解決する
type Admin = User & { permissions: string[]; role: ‘admin’ };
コンパイラ内部の視点
Intersection 型 `A & B` は、コンパイラにとって「AとBの両方のプロパティを持つ型」として即座に評価される。継承関係（`extends`）による親型の検索処理よりも、コンパイラが型解決を行う際の計算コストが低く、かつ型同士の依存関係が疎になるため、静的解析の効率が向上する。
—
3. 型の「防壁」：コンポジションによるカプセル化とガード
コンポジションは、セキュリティの観点からも極めて強力だ。特定の権限を持つデータのみを関数に渡したい場合、継承ではサブクラスが親クラスのメソッドを継承してしまうため、不必要な情報が漏洩するリスクがある。
// 必要な型パーツのみを抽出して型ガードを適用する
function validateAccess(data: Identity & { role: ‘admin’ }) {
// ここでは email や createdAt へのアクセスは不要であり、
// 型定義上もそれらが含まれていても無視できる（構造的部分型の恩恵）
console.log(`Granting access to: ${data.id}`);
}
この手法は、Node.jsのイベントループにおいて、特定のタスクがメモリ上の不必要なフィールドを保持し続ける「メモリリーク（クロージャによる保持）」を防ぐ上でも有効である。不要な型パーツを分離することで、メモリ空間上のオブジェクトレイアウトを最適化できるからだ。
—
4. 伝説的アーキテクトからの提言
コンポジションに移行することは、単なるコードスタイルの変更ではない。それは「型システムをランタイムのメタデータとして再定義する」というエンジニアリングの転換だ。
- 継承（`extends`）: 物理的な制約が強く、再利用性が低い。単一責任原則に反しやすい。
- コンポジション（`&` / `Pick` / `Omit`）: 型をデータとして扱い、必要な機能を「注入」する。疎結合かつ高い拡張性を保つ。
結論
TypeScriptの真価は、継承を駆使したクラス階層の構築にあるのではない。「型を小さな断片（Atom）に分解し、ユースケースごとに動的に合成する」という、関数型アプローチの適用にこそある。
今日のタスクから、`extends` をすべて削除してみる勇気を持ってほしい。あなたのコードベースが、どれほど軽快かつ堅牢に生まれ変わるか、コンパイラの挙動とともに実感できるはずだ。
型は設計の写し鏡である。複雑な階層を作れば、複雑なバグが生まれる。シンプルに合成せよ。それが、システムを掌握するための唯一の道だ。