1. はじめに
🎯 この記事でわかること
-
インターフェースって何のためにあるの？🤔
-
インターフェースを大きくしすぎると何が起きる？💥
-
インターフェース分離の原則（ISP）の考え方✨
📌 そもそもインターフェースとは？
インターフェースは、
👉 「このクラスは、これができますよ」という約束事
を表すものです 📄✨
TypeScriptでは、
「どんなメソッドを持つか」 を決める設計図のような存在です。
2. 失敗事例
まずは失敗例を見てみましょう。 👀
❌ よくある失敗：なんでも入れたインターフェース
// 悪い例：何でもできる巨大なインターフェース
interface Restaurant {
makeHamburger(): void;
makeRamen(): void;
makeSushi(): void;
makeCurry(): void;
makeDessert(): void;
}
一見すると
「全部まとまっていて便利そう！」
に見えますよね 😊
でも、ここに落とし穴があります ⚠️
🤖 問題が起きるケース：ハンバーガーショップを作りたい
// ハンバーガーショップなのに全部実装しなきゃいけない...
class HamburgerShop implements Restaurant {
makeHamburger(): void {
console.log("🍔 美味しいハンバーガーを作ります！");
}
// 使わないのに実装が必要...😢
makeRamen(): void {
throw new Error("ラーメンは作れません");
}
makeSushi(): void {
throw new Error("寿司は作れません");
}
makeCurry(): void {
throw new Error("カレーは作れません");
}
makeDessert(): void {
throw new Error("デザートは作れません");
}
}
😢 何がつらいの？
-
ハンバーガーショップは、ハンバーガーとデザートしか作れない
-
それなのに メソッドを無理やり実装
-
不要なメソッドが増えて、意味がわかりにくくなる
👉 「使わない機能に依存している状態」 です。
3. 💡 インターフェース分離の原則（ISP）とは？
ここで登場するのが インターフェース分離の原則(ISP) です ✨
📖 ISPの考え方
クラスは、自分が使わないメソッドに依存してはいけない
初心者向けに言い換えると👇
- 👉 「必要な機能だけを約束しよう」
- 👉 「1つのインターフェースに詰め込みすぎない」
✅ 解決策：役割ごとに分ける
インターフェースを 「できることごと」 に分割してみましょう ✂️✨
// 良い例：小さく分離されたインターフェース
interface BurgerMaker {
makeHamburger(): void;
}
interface RamenMaker {
makeRamen(): void;
}
interface SushiMaker {
makeSushi(): void;
}
interface DessertMaker {
makeDessert(): void;
}
👉 それぞれが とてもシンプルになりましたね 😊
🧑 ハンバーガーショップクラスの場合
// ハンバーガーショップは必要なインターフェースだけ実装
class HamburgerShop implements BurgerMaker, DessertMaker {
makeHamburger(): void {
console.log("🍔 美味しいハンバーガーを作ります！");
}
makeDessert(): void {
console.log("🍰 デザートもご用意できます！");
}
}
✔ 必要なインターフェースだけを実装
✔ 無理な実装は一切なし
🤖 ラーメン屋さんの場合
// ラーメン屋さんはラーメンだけ
class RamenShop implements RamenMaker {
makeRamen(): void {
console.log("🍜 本格的なラーメンを作ります！");
}
}
🎉 使わないメソッドは最初から持っていません！
🌟 何が良くなったの？
✅ 不要なメソッドを書かなくていい
✅ クラスの役割がわかりやすい
✅ 変更があっても影響が少ない
✅ コードが自然で読みやすい
👉 これが インターフェース分離の原則（ISP） の効果です ✨
4. 🧠 覚え方（初心者向け）
- 📌 「インターフェースは小さく作る」
- 📌 「使わない約束は、しない」
この2つを覚えておけばOKです 👍
🚀 実務でありがちな場面
-
1つのinterfaceに項目が大量にある 😵
-
implementsしたら空メソッドだらけ
-
「とりあえず共通化」でinterfaceが肥大化
👉 そんなときは
「このインターフェース、役割多すぎない？」
と考えてみましょう 👀✨
5. ✨ まとめ
-
ISPは ムダな依存をなくすための原則
-
インターフェースは 役割ごとに分ける
-
クラスは 必要な機能 だけを持つ
-
TypeScriptのinterfaceは小さいほど使いやすい
6. 次回予告
次回はいよいよ 最終回：第5回 依存関係逆転の原則（DIP）🔄
SOLID原則の集大成として、
「依存関係をどう設計するか」 をやさしく解説していきます。
次回はこちら
- 第１回からご覧になるならこちら
7. おわりに
インターフェース分離の原則（ISP）は、
最初は少し地味に見えるかもしれません 🤔
でも実は、
-
「なんでこのクラス、こんなメソッド持ってるんだろう？」
-
「implementsしたら空のメソッドだらけ…😵」
-
「変更したら関係ないところが壊れた…💥」
といった 実務でよくあるつらさを防ぐための、とても大切な考え方です。
ISPを意識すると、
インターフェースは自然と 小さく・シンプルになり、
-
クラスの役割がはっきりする ✨
-
コードが読みやすくなる 👀
-
将来の変更にも強くなる 💪
といった良いことがたくさん起こります。
はじめのうちは、
- 「とりあえず共通化」
- 「あとで使うかもしれないから入れておく」
とやりがちですが、そんなときこそ思い出してほしいのが ISP です 💡
- 👉 「この機能、本当に全員必要？」
- 👉 「インターフェース、役割多すぎない？」
この問いを持つだけで、設計の質はぐっと上がります。
最後まで読んでいただきありがとうございました！🎉
よろしければ他の記事もご覧頂けるとすごくうれしいです。
👍 いいね / 💬 コメントいただけると励みになります！