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 です 💡

👉 「この機能、本当に全員必要？」
👉 「インターフェース、役割多すぎない？」

この問いを持つだけで、設計の質はぐっと上がります。

最後まで読んでいただきありがとうございました！🎉

よろしければ他の記事もご覧頂けるとすごくうれしいです。

👍 いいね / 💬 コメントいただけると励みになります！