SOLID — 5つの原則が守ろうとしている1つのこと

What — 5つの原則と、備えている変更

開放閉鎖原則：冒頭の事故を直す

function calcFee(method, amount) {
if (method === 'credit') return amount * 0.036;
if (method === 'paypay') return amount * 0.028;
if (method === 'bank')   return 330;
// ← コンビニ払いを足すには、ここを書き換える
}

// 同じ形の分岐が、アプリ内に 12 箇所

依存性逆転：何を逆転させているのか

これが5つの中で最も誤解されます。**逆転しているのは「依存の向き」**です。

素朴な構造（上位が下位を知っている）

  OrderService  ──────▶  MySQLOrderRepository
  （業務ロジック）           （DB の詳細）

  → DB を変えると OrderService も変わる
  → テストに実 DB が必要

逆転後（両者が抽象を知っている）

  OrderService  ──────▶  OrderRepository（インターフェース）
                              ▲
                              │ implements
                    MySQLOrderRepository

  → 矢印が下から上を向いた = 逆転
  → OrderService は MySQL を知らない
  → テストではメモリ実装を差し込める

インターフェースを、上位（業務ロジック）側に置くのが要点です。下位のパッケージに置くと、結局上位が下位を参照することになり、逆転していません。

Why — なぜ5つに分かれているのか

SOLID は、変更の種類ごとに対策を並べたものです。

だから「全部守るべき」ではありません。その変更が来ないなら、その原則は要らないのです。

決済手段が今後絶対に増えないなら、if の分岐で構いません。DB を変える予定がまったくないなら、リポジトリインターフェースは過剰かもしれません。

リスコフ置換原則が壊れる典型

class Bird {
  fly() { ... }
}
class Penguin extends Bird {
  fly() { throw new Error('ペンギンは飛べません'); }  // ← 違反
}

Bird として扱っているコードが Penguin で落ちます。使う側は「もしペンギンだったら」という確認を書く羽目になり、継承したのに型で扱えないという本末転倒な状態になります。

実務でよく見る形はこちらです。

class ReadOnlyRepository extends Repository {
  save() { throw new Error('読み取り専用です'); }
}

解決は、そもそも継承しないこと。Readable と Writable を分ければ（= インターフェース分離）、型で正しく表現できます。

インターフェース分離が効く場面

// 分離されていない
interface Repository {
  find(id): Entity;
  save(e): void;
  delete(id): void;
  bulkImport(file): void;
  exportCsv(): string;
}

// 読むだけの機能も、全部を実装させられる

// 分離した
interface Readable  { find(id): Entity; }
interface Writable  { save(e): void; delete(id): void; }
interface Importable { bulkImport(file): void; }

// 必要なものだけを実装し、必要なものだけを要求できる
function showDetail(repo: Readable, id) { ... }

showDetail が Readable だけを要求すれば、この関数が書き込みをしないことが型で保証されます。読む人にも分かるし、テストのモックも小さくて済みます。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。