こんにちは！TypeScriptの世界へようこそ。チーフアーキテクトの私です。
「よし、TypeScriptの型定義をがんばるぞ！」と意気込んでコードを書き始めたものの、次から次へと出てくる見慣れない記号やルールに、「もう無理かも……」とそっとエディタを閉じそうになっていませんか？ 大丈夫です、安心してください。最初は誰もが同じ道を通ります。
今回は、TypeScriptの数ある機能の中でも、知っていると「おっ、ちょっとスマートじゃん！」とドヤ顔できる（かもしれない）「インターフェースの宣言結合（Declaration Merging）」という機能について、お話ししていきます。
難しそうな名前をしていますが、身近な例えを使えば「なぁんだ、そういうことか！」とスッと腑に落ちるはずです。コーヒーでも飲みながら、気楽に読んでいってくださいね。
—
1. 宣言結合って、ざっくり言うと何？
いきなりコードを書く前に、まずはイメージから入りましょう。
想像してみてください。あなたは今、自分専用の「秘密のノート」を持っています。このノートの最初のページには、こう書いてありました。
- 「持ち物リスト：ペン」
数日後、同じノートの別のページに、あなたはこう書き足しました。
- 「持ち物リスト：ノート」
さて、後から見返したとき、この「持ち物リスト」はどうなっているでしょうか？
わざわざ新しいノートを買わなくても、最初のリストの下に「ノート」が追加されて、結果的に「ペン」と「ノート」の両方が書かれた、ちょっと豪華なリストにパワーアップしていますよね。
TypeScriptの「宣言結合（Declaration Merging）」も、これとまったく同じことをやっています。
同じ名前の `interface`（インターフェース：設計図のようなもの）をバラバラの場所で定義したとき、TypeScriptが「おっ、同じ名前だな！じゃあ、中身を合体させておこう！」と、自動的にひとつの大きな設計図にまとめてくれる機能、それが宣言結合なんです。
—
2. 実際にコードで見てみよう
百聞は一見にしかず。簡単なコードでその魔法を体験してみましょう。
例えば、Webサイトで使う「ユーザー情報」の設計図を作るとします。最初は名前と年齢だけ管理するつもりでした。
// 1. 最初はシンプルな設計図を作る
interface User {
name: string; // お名前
age: number; // ご年齢
}
しばらく開発を進めていると、「あ、やっぱりメールアドレスも保存したくなった！」となりました。
ふつうのプログラミング言語だと、元のコードを書き換えに行かないといけない気がしますよね。でも、TypeScriptならこう書けちゃうんです。
// 2. びっくり！ 同じ「User」という名前で、別のプロパティを追加しちゃう
interface User {
email: string; // メールアドレスを追加！
}
さて、ここで不思議なことが起きます。
別々の場所（あるいは同じファイル内）で定義されたこの2つの `User` ですが、TypeScriptは裏側でこう解釈しています。
> 「ほうほう、`User` って名前の設計図がふたつあるな。よし、中身を全部合体させて、こういう形にしておこう！」
// TypeScriptの頭の中では、こう合体（マージ）されている！
interface User {
name: string;
age: number;
email: string; // 自動的に合体！
}
これを確認するために、実際にこの `User` 型の変数を作ってみましょう。
// エディタに貼り付けて試してみてくださいね
const myProfile: User = {
name: “山田 太郎”,
age: 28,
email: “yamada@example.com” // ちゃんと3つ全部揃えないと、TypeScriptが怒ってくれます
};
console.log(myProfile);
すごいでしょう？ 元のコードを汚さずに、後からこっそり設計図を拡張できる。これが宣言結合の優しい魔法です。
—
3. 「これ、一体どんなときに使うの？」実務でのリアルな話
「仕組みは分かったけど、これっていつ使うの？」という疑問が湧きますよね。
実は、私たちが普段のWeb制作やアプリ開発で、この宣言結合を自分からゴリゴリ書くことは、実はそこまで多くありません。
一番よく出会うのは、「外部のライブラリ（他人が作った便利な道具箱）を拡張するとき」です。
例えば、世の中でよく使われているフレームワークやライブラリの中には、「ここ、あとから自分の好きなようにプロパティを追加していいよ！」と、あえて隙間を空けてくれているものがあります。
そんなとき、宣言結合を使うと、ライブラリの元のコードを書き換えることなく、自分のプロジェクト専用に型をパワーアップさせることができるんです。
ちょっとした実例：セッション情報の拡張
ログインしているユーザーの情報を扱う `Session` という型があったとします。
// 外部のライブラリ（または別のファイル）にあらかじめ用意されている基本の型
interface Session {
userId: string;
}
ここに、あなたのプロジェクト独自の「権限（role）」という情報を追加したくなりました。そんなときは、自分のコード側でこう書けばOKです。
// 自分のプロジェクトのファイルで、同じ名前で定義するだけ！
interface Session {
role: ‘admin’ | ‘user’; // 管理者か一般ユーザーか
}
// 結果として、Session型は userId と role の両方を持つようになる
const currentSession: Session = {
userId: “user_12345”,
role: “admin” // 気持ちよく補完が効きます！
};
既存の仕組みを壊さず、優しく拡張していく。チーム開発や大きなプロジェクトにおいて、この考え方はすごく大切にされています。
—
4. 注意しておいてほしい「落とし穴」
ここまで良いことばかりお話ししてきましたが、少しだけ注意点があります。
「同じ名前なら何でも合体できるんでしょ？」と思って、もしこんなことをしたらどうなるでしょうか？
interface Box {
size: string;
}
// やっちゃった例：同じ名前で、中の「型」を矛盾させてしまった
interface Box {
size: number; // さっきは string だったのに！
}
これ、TypeScriptのコンパイラ（先生）は、「えっ、どっちを信じればいいの……？」とパニックを起こしてエラーを出してしまいます（正確には、同じプロパティで異なる型を上書きすることはできません）。
基本ルール：
- 違うプロパティを追加するのは大歓迎！
- すでに存在しているプロパティの型を、後からこっそり変えようとするのはNG！
もしエラーが出たら、「あ、喧嘩させちゃったな」と思って、プロパティ名がかぶっていないか確認してあげてくださいね。
—
おわりに
お疲れ様でした！
「インターフェースの宣言結合」という、一見すると呪文のような難しそうな言葉も、こうして紐解いてみると「なんだ、同じ名前の設計図を自動で合体させてくれる便利な仕組みなんだな」と分かっていただけたのではないでしょうか。
TypeScriptは、最初はルールが多くて厳しく感じるかもしれませんが、実は私たちの開発をそっと助けてくれる心強い味方です。
つまずいたときは、今日みたいに身近なイメージに置き換えて考えてみてくださいね。
あなたのTypeScriptの旅が、少しでも楽しく、ワクワクするものになりますように。それでは、また次の記事でお会いしましょう！
コメント