PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference Japan 2025

Shogo Kawase / @shogogg Jun. 28 2025 PHP Conference Japan
2025 PHP開発者のための SOLID原則再入門

SOLID原則を完全に理解する Today’s Goal

Today’s Goal • SOLID原則を理解する • SOLID原則がもたらす価値について理解する • SOLID原則に則った設計ができるようになる • SOLID原則を参照してコミュニケーションできるようになる

SOLID原則とは • Simple Responsibility Principle / 単一責任の原則 • Open/Closed Principle
/ 開放閉鎖の原則 • Liskov Substitution Principle / リスコフの置換原則 • Interface Segregation Principle / インターフェース分離の原則 • Dependency Inversion Principle / 依存性逆転の原則

なんだかむずかしい……

なんのために守るのかよくわからない……

そんな人達のために……

PHPカンファレンス名古屋2025にて https://speakerdeck.com/shogogg/5fen-deli-jie-suru-solid-yuan-ze

5分はキツかった

今日は25分ある！（当社比5倍）

今日こそ終わらせる！

自己紹介河瀨翔吾 / Shogo Kawase 株式会社 PR TIMES ソフトウェアエンジニア（2024.12〜）
I LOVE... 妻 / 型安全 / アジャイル / ももいろクローバーZ F1 / マリオカート shogogg shogogg

おしながき 1. SOLID原則がソフトウェア開発にもたらす価値と代償 2. 前提知識：DRY原則について 3. SOLID原則の5つの原則について 4. まとめ

ソフトウェア開発の世界にはいくつも原則がある • DRY原則 / Don’t Repeat Yourself • YAGNI原則 /
You Aren't Gonna Need It • KISS原則 / Keep It Simple, Stupid • OAOO原則 / Once And Only Once • SOLID原則 • 驚き最小の原則

You Aren't Gonna Need It • KISS原則 / Keep It Simple, Stupid • OAOO原則 / Once And Only Once • SOLID原則 • 驚き最小の原則すべての原則を理解して常に守るようにすれば、どんな場合でも最高のソフトウェアになるってことだな！

You Aren't Gonna Need It • KISS原則 / Keep It Simple, Stupid • OAOO原則 / Once And Only Once • SOLID原則 • 驚き最小の原則原則こそ至高！絶対のルール！

You Aren't Gonna Need It • KISS原則 / Keep It Simple, Stupid • OAOO原則 / Once And Only Once • SOLID原則 • 驚き最小の原則原則こそ至高！絶対のルール！違うよ、全然違うよ

原則 ≠ 絶対的なルール • 原則同士が対立し、トレードオフの関係になることも DRY/OAOO/SOLID を重視 → 設計が複雑化 →
KISS原則違反 • 原則は手段であって目的ではないすべての原則は何らかの価値を得るための手段。原則を守ることが目的ではない。 • 文脈によって価値の優先順位は変わる「売れるかどうかわからない」場合と「数年間の運用・拡張が決まっている」場合では重視する価値が異なる

SOLID原則がソフトウェア開発にもたらす価値 • 安定性・安全性ソフトウェアを変更しても、障害が起きにくくなる • 拡張性・変更容易性仕様変更や機能追加に柔軟に対応できるようになる • テスト容易性モジュールごとのテストがしやすくなる
• 保守性・可読性コードの責任と役割が明確・シンプルになり、開発が円滑化する

もちろん代償もある • 設計・実装コストの増加原則に則った設計・抽象化のため初期段階では時間や手間が掛かる • 学習コストの増加チームメンバーの習熟度によっては理解が難しくなる可能性がある • さじ加減の難しさやりすぎてしまうと逆に可読性やシンプルさを失ってしまうことも

しかし時は大AI時代

もちろん代償もある！……けども？ • 設計・実装コストの増加原則に則った設計・抽象化のため初期段階では時間や手間が掛かる • 学習コストの増加チームメンバーの習熟度によっては理解が難しくなる可能性がある • さじ加減の難しさやりすぎてしまうと逆に可読性やシンプルさを失ってしまうことも
• ➡ AIを使えばここのコストは大幅に軽減できそう！ • ➡ この資料を使って説明すれば解決できるかも！ • ➡ こればかりは場数を踏んで慣れるしかない？

理解して使いこなそう！

なぜここでDRY原則の話をするのか • DRY原則は数ある原則の中でも特に有名なもの • しかし誤解されていることがとっても多い • SOLID原則を理解する上で、DRY原則の正しい理解は不可欠

Don’t Repeat Yourself DRY is a principle of software development
which states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". By not writing the same information over and over again, our code is more maintainable, more extensible, and less buggy. Getting Started with Rails より

Don’t Repeat Yourself DRYはソフトウェア開発の原則であり「あらゆる知識は、システム内において単一で、曖昧さのない、信頼できる表現でなければならない」と述べています。同じ情報を何度も繰り返し書かないことで、コードはより保守しやすくなり、拡張しやすくなり、バグも少なくなります。
Getting Started with Rails の内容を翻訳

Don’t Repeat Yourself DRYはソフトウェア開発上の原則であり、「システムを構成する知識のあらゆる部品は、常に単一であり、明確であり、信頼できる形で表現されていなければならない」というものです。同じコードを繰り返し書くことを徹底的に避けることで、コードが保守しやすくなり、容易に拡張できるようになり、バグも減らせます。
Rails をはじめよう（公式日本語訳）より引用

Don’t Repeat Yourself DRYはソフトウェア開発上の原則であり、「システムを構成する知識のあらゆる部品は、常に単一であり、明確であり、信頼できる形で表現されていなければならない」というものです。同じコードを繰り返し書くことを徹底的に避けることで、コードが保守しやすくなり、容易に拡張できるようになり、バグも減らせます。
Rails をはじめよう（公式日本語訳）より引用なぜか「情報」じゃなくて「コード」になっている……

DRY原則を正しく理解しよう • 「コードの重複」ではなく「知識の重複」を避ける • 「◦◦に関する知識・処理はここにあり、他にはない」状態を作る • 仕様とコードの関係がシンプルになり、変更しやすく、想定外のバグを減らせる 💡Tips
コードの重複を徹底的に避けるのは OAOO（Once And Only Once）原則

1. Simple Responsibility Prinsiple 単一責任の原則

単一責任の原則 “There should never be more than one reason for
a class to change.” 意訳：クラスを変更する理由が複数あってはならない。

単一責任の原則：わかりやすく言うと？ • ひとつのクラスや関数に機能をいくつも詰め込まない • 既にあるクラスや関数を軽率に使い回さない DRY原則を勘違いしているとやってしまいがち

アンチパターン例①

// 商品を注文する function makeOrder(array $order): void { $this->insertRecord($order); $this->makePayment($order); $this->sendmail($order);
} ECサイトの注文処理ができたぞ！

// 商品を注文する function makeOrder(array $order): void { $isReservation = $this->isReservation($order);
$this->insertRecord($order); // 予約の場合は決済処理を行わない仕様 if ($isReservation) { $this->makePayment($order); } // 予約かどうかでメールの内容を変える $mailTemplate = $isReservation ? 'reserve' : 'order'; $this->sendmail($mailTemplate, $order); } 予約に対応？任せとけ！！

$isLottery = $this->isLottery($order); // 抽選かどうかで挿入するテーブルが変わる if ($isLottery) { $this->insertLotteryRecord($order); } else { $this->insertOrderRecord($order); } // 予約 or 抽選の場合は決済を行わない仕様 if ($isReservation || $isLottery) { $this->makePayment($order); } // 通常 or 予約 or 抽選でメールの内容を変える $mailTemplate = $this->determineMailTemplate($isReservation, $isLottery); $this->sendmail($mailTemplate, $order); } 抽選機能？余裕だぜ！！

$isLottery = $this->isLottery($order); $isGlitch2 = $this->isGlitch2($order); // 新型ゲーム機「 Glitch 2」の場合は申し込み条件を満たしている必要がある if ($isGlitch2) { $this->ensureGlitch2Requirements($order); } // 抽選かどうかで挿入するテーブルが変わる if ($isLottery) { $this->insertLotteryRecord($order); } else { $this->insertOrderRecord($order); } // 予約 or 抽選の場合は決済を行わない仕様 if ($isReservation || $isLottery) { $this->makePayment($order); } // 通常 or 予約 or 抽選でメールの内容を変える $mailTemplate = $this->determineMailTemplate($isReservation, $isLottery); $this->sendmail($mailTemplate, $order); } 特別な条件の販売にも対応するぞ！

$isLottery = $this->isLottery($order); $isGlitch2 = $this->isGlitch2($order); // 新型ゲーム機「 Glitch 2」の場合は申し込み条件を満たしている必要がある if ($isGlitch2) { $this->ensureGlitch2Requirements($order); } // 抽選かどうかで挿入するテーブルが変わる if ($isLottery) { $this->insertLotteryRecord($order); } else { $this->insertOrderRecord($order); } // 予約 or 抽選の場合は決済を行わない仕様 if ($isReservation || $isLottery) { $this->makePayment($order); } // 通常 or 予約 or 抽選でメールの内容を変える $mailTemplate = $this->determineMailTemplate($isReservation, $isLottery); $this->sendmail($mailTemplate, $order); } テストを書くのがしんどい……

アンチパターン解説①：機能を詰め込む • コードが複雑になる ➡ 可読性・保守性が低下 • テストが大変になる ➡ テストコードの可読性・保守性も低下

アンチパターン例②

final raedonly class MemberService { // 会員情報を DB から取得して返す function
getMemberData(int $memberId): array { // 会員情報 + 注文履歴を返す return [ 'member' => $this->lookupMember($memberId), 'orders' => $this->lookupOrders($memberId), ); } } final readonly class MemberController { // 会員情報取得 API function get(int $memberId): Response { // getMemberData を呼び出してレスポンスを返す } } 会員情報取得APIを実装したよ！

getMemberData(int $memberId): array { // 会員情報 + 注文履歴を返す return [ 'member' => $this->lookupMember($memberId), 'orders' => $this->lookupOrders($memberId), ); } } final readonly class SomeSubparService { // 会員情報と注文履歴から何かをする処理 function doSomething(int $memberId): array { // getMemberData を呼び出してごにょごにょする } } お、こんなとこに便利なものが！ DRY原則だ！流用するぞー！

getMemberData(int $memberId): array { // 会員情報 + 注文履歴を返す // 会員情報を返す return [ 'member' => $this->lookupMember($memberId), 'orders' => $this->lookupOrders($memberId), ); } } final readonly class MemberController { // 会員情報取得 API function get(int $memberId): Response { // getMemberData を呼び出してレスポンスを返す } } API仕様が変わったから注文履歴はレスポンスから消すよ

getMemberData(int $memberId): array { // 会員情報 + 注文履歴を返す // 会員情報を返す return [ 'member' => $this->lookupMember($memberId), 'orders' => $this->lookupOrders($memberId), ); } } final readonly class SomeSubparService { // 会員情報と注文履歴から何かをする処理 function doSomething(int $memberId): array { // getMemberData を呼び出してごにょごにょする } } 何もしてないのに壊れた……

アンチパターン解説②：用途外の流用 • 予想外の範囲に影響する ➡ 障害の可能性UP • 影響範囲が広がりすぎる ➡ バグ修正・機能追加の工数増加 •
怖くて修正できなくなる ➡ 技術的負債の増加

単一責任の原則：まとめ以下のアンチパターンを避け、モジュールの責務をシンプルに保とう • ひとつのクラスや関数に機能をいくつも詰め込まない • 既にあるクラスや関数を軽率に使い回さない

2. Open/Closed Prinsiple 開放閉鎖の原則

OCP/開放閉鎖の原則 “Software entities (classes, modules, functions, etc.) should be open
for extension, but closed for modification.” 意訳：クラスや関数は拡張に対して開かれ、修正に対して閉じているべきである。

OCP/開放閉鎖の原則 “Software entities (classes, modules, functions, etc.) should be open
for extension, but closed for modification.” 意訳：クラスや関数は拡張に対して開かれ、修正に対して閉じているべきである。ちょっと何言ってるかわかんない

開放閉鎖の原則：わかりやすく言うと？ソフトウェアに機能を追加する際に…… • 修正に対して閉じている＝既存のコードを変更せずに • 拡張に対して開いている＝新しいコードの追加で対応できる
ように設計しましょう、ということ。

アンチパターン例①

$isLottery = $this->isLottery($order); $isGlitch2 = $this->isGlitch2($order); // 新型ゲーム機「 Glitch 2」の場合は申し込み条件を満たしている必要がある if ($isGlitch2) { $this->ensureGlitch2Requirements($order); } // 抽選かどうかで挿入するテーブルが変わる if ($isLottery) { $this->insertLotteryRecord($order); } else { $this->insertOrderRecord($order); } // 予約 or 抽選の場合は決済を行わない仕様 if ($isReservation || $isLottery) { $this->makePayment($order); } // 通常 or 予約 or 抽選でメールの内容を変える $mailTemplate = $this->determineMailTemplate($isReservation, $isLottery); $this->sendmail($mailTemplate, $order); }

• 通常・予約・抽選という複数の注文方法に1つのコードで対応している • さらに特殊な条件の抽選という条件が加わり、条件分岐だらけに • コードが複雑になり、可読性・保守性が低下 • テストが大変になり、テストコードの可読性・保守性も低下アンチパターン例①：解説

解消例（Strategy Pattern）

interface OrderStrategyInterface { public function makeOrder(array $order): void; } final
class OrdinaryOrderStrategy implements OrderStrategyInterface { // 通常注文向けの実装 ... } final class ReservationOrderStrategy implements OrderStrategyInterface { // 予約注文向けの実装 ... } // ... final class OrderStrategyFactory { public function create(array $order): OrderStrategyInterface { // 注文内容に応じて適切な OrderStrategyInterface の実装を返す... } } // 商品を注文する function makeOrder(OrderStrategyFactory $factory, array $order): void { $strategy = $factory->create($order); $strategy->makeOrder($order); }

class OrdinaryOrderStrategy implements OrderStrategyInterface { // 通常注文向けの実装 ... } final class ReservationOrderStrategy implements OrderStrategyInterface { // 予約注文向けの実装 ... } // ... final class OrderStrategyFactory { public function create(array $order): OrderStrategyInterface { // 注文内容に応じて適切な OrderStrategyInterface の実装を返す... } } // 商品を注文する function makeOrder(OrderStrategyFactory $factory, array $order): void { $strategy = $factory->create($order); $strategy->makeOrder($order); } 注文種別ごとの戦略を定義するインターフェース

class OrdinaryOrderStrategy implements OrderStrategyInterface { // 通常注文向けの実装 ... } final class ReservationOrderStrategy implements OrderStrategyInterface { // 予約注文向けの実装 ... } // ... final class OrderStrategyFactory { public function create(array $order): OrderStrategyInterface { // 注文内容に応じて適切な OrderStrategyInterface の実装を返す... } } // 商品を注文する function makeOrder(OrderStrategyFactory $factory, array $order): void { $strategy = $factory->create($order); $strategy->makeOrder($order); } 注文種別ごとに異なる実装（クラス）を定義する

class OrdinaryOrderStrategy implements OrderStrategyInterface { // 通常注文向けの実装 ... } final class ReservationOrderStrategy implements OrderStrategyInterface { // 予約注文向けの実装 ... } // ... final class OrderStrategyFactory { public function create(array $order): OrderStrategyInterface { // 注文内容に応じて適切な OrderStrategyInterface の実装を返す ... } } // 商品を注文する function makeOrder(OrderStrategyFactory $factory, array $order): void { $strategy = $factory->create($order); $strategy->makeOrder($order); } 戦略を選択するためのファクトリークラスを実装

class OrdinaryOrderStrategy implements OrderStrategyInterface { // 通常注文向けの実装 ... } final class ReservationOrderStrategy implements OrderStrategyInterface { // 予約注文向けの実装 ... } // ... final class OrderStrategyFactory { public function create(array $order): OrderStrategyInterface { // 注文内容に応じて適切な OrderStrategyInterface の実装を返す... } } // 商品を注文する function makeOrder(OrderStrategyFactory $factory, array $order): void { $strategy = $factory->create($order); $strategy->makeOrder($order); } 注文処理からは適切な戦略を呼び出す

• 似て非なる注文処理＝戦略をインターフェース化し、注文方法ごとに独立したクラスとして定義する • 新しい注文方法が増えた場合、StrategyInterface を継承する新しいクラスの追加のみで対応可能となる • 新しい注文方法が増えても、既存のクラスを修正する必要がないため
既存機能で不具合が起きる可能性がぐっと低くなる OCP適用例：ストラテジーパターン

アンチパターン例②

// 消費税を表す列挙型 enum Tax { case TaxFree; // 非課税 case
ConsumptionTax; // 消費税・課税対象 } // 商品クラス final readonly class Item { public function getPriceWithTax(Tax $tax): int { return match ($tax) { Tax::TaxFree => $this->price, Tax::ConsumptionTax => (int)floor($this->price * 1.10), }; } }

ConsumptionTax; // 消費税・課税対象 } // 商品クラス final readonly class Item { public function getPriceWithTax(Tax $tax): int { return match ($tax) { Tax::TaxFree => $this->price, Tax::ConsumptionTax => (int)floor($this->price * 1.10), }; } } 商品クラス側で match 式を使って計算している

ConsumptionTax; // 消費税・課税対象 case ReducedConsumptionTax; // 消費税・課税対象（軽減税率） } // 商品クラス final readonly class Item { public function getPriceWithTax(Tax $tax): int { return match ($tax) { Tax::TaxFree => $this->price, Tax::ConsumptionTax => (int)floor($this->price * 1.10), }; } } 消費税率に「軽減税率」が増えた！

ConsumptionTax; // 消費税・課税対象 case ReducedConsumptionTax; // 消費税・課税対象（軽減税率） } // 商品クラス final readonly class Item { public function getPriceWithTax(Tax $tax): int { return match ($tax) { Tax::TaxFree => $this->price, Tax::ConsumptionTax => (int)floor($this->price * 1.10), }; } } $tax に軽減税率が渡されるとエラーが起きる！

ConsumptionTax; // 消費税・課税対象 case ReducedConsumptionTax; // 消費税・課税対象（軽減税率） } // 商品クラス final readonly class Item { public function getPriceWithTax(Tax $tax): int { return match ($tax) { Tax::TaxFree => $this->price, Tax::ConsumptionTax => (int)floor($this->price * 1.10), Tax::ReducedConsumptionTax => (int)floor($this->price * 1.08), }; } } 税率が増えるたびに match 式の条件を増やす必要がある

• パターンが増える度に条件分岐が増え、既存コードに修正が発生する ➡ 影響範囲・対応コストが増える ➡ 不具合のリスク・テストの負荷が増えるアンチパターン例②：解説もし商品クラス以外にも消費税計算があったら……？

解消例

// 商品クラス final readonly class Item { public function getPriceWithTax(Tax
$tax): int { return $this->price + $tax->compute($this->price); } } // 消費税を表す型 abstract class Tax { public function compute(int $amount): int { return (int)floor($amount * $this->rate / 100); } } // 非課税 final class TaxFree extends Tax { protected int $rate = 0; } // 消費税・課税対象 final class ConsumptionTax extends Tax { protected int $rate = 10; }

$tax): int { return $this->price + $tax->compute($this->price); } } // 消費税を表す型 abstract class Tax { public function compute(int $amount): int { return (int)floor($amount * $this->rate / 100); } } // 非課税 final class TaxFree extends Tax { protected int $rate = 0; } // 消費税・課税対象 final class ConsumptionTax extends Tax { protected int $rate = 10; } 消費税を表す型をインターフェースや抽象クラスとして定義

$tax): int { return $this->price + $tax->compute($this->price); } } // 消費税を表す型 abstract class Tax { public function compute(int $amount): int { return (int)floor($amount * $this->rate / 100); } } // 非課税 final class TaxFree extends Tax { protected int $rate = 0; } // 消費税・課税対象 final class ConsumptionTax extends Tax { protected int $rate = 10; } 税額の計算は消費税クラスに実装する

$tax): int { return $this->price + $tax->compute($this->price); } } // 消費税を表す型 abstract class Tax { public function compute(int $amount): int { return (int)floor($amount * $this->rate / 100); } } // 非課税 final class TaxFree extends Tax { protected int $rate = 0; } // 消費税・課税対象 final class ConsumptionTax extends Tax { protected int $rate = 10; } 税率ごとにサブクラスを定義する

$tax): int { return $this->price + $tax->compute($this->price); } } // 消費税を表す型 abstract class Tax { public function compute(int $amount): int { return (int)floor($amount * $this->rate / 100); } } // 非課税 final class TaxFree extends Tax { protected int $rate = 0; } // 消費税・課税対象 final class ConsumptionTax extends Tax { protected int $rate = 10; } 商品クラスは渡された税率のメソッドを呼び出すだけ

$tax): int { return $this->price + $tax->compute($this->price); } } // 消費税を表す型 abstract class Tax { public function compute(int $amount): int { return (int)floor($amount * $this->rate / 100); } } // 非課税 final class TaxFree extends Tax { protected int $rate = 0; } // 消費税・課税対象 final class ConsumptionTax extends Tax { protected int $rate = 10; } // 消費税・課税対象（軽減税率） final class ReducedConsumptionTax extends Tax { protected int $rate = 8; } 新しい税率は新しいクラスを定義

$tax): int { return $this->price + $tax->compute($this->price); } } // 消費税を表す型 abstract class Tax { public function compute(int $amount): int { return (int)floor($amount * $this->rate / 100); } } // 非課税 final class TaxFree extends Tax { protected int $rate = 0; } // 消費税・課税対象 final class ConsumptionTax extends Tax { protected int $rate = 10; } // 消費税・課税対象（軽減税率） final class ReducedConsumptionTax extends Tax { protected int $rate = 8; } 新しい税率は新しいクラスを定義既存の商品クラスは変更せずに機能追加ができた！

• シンプルな処理だから、と安直に if 文や switch 文、match 式を書くのではなく、知識・情報を1ヶ所にまとめるよう抽象化することで、自然と
OCP に沿った設計となる • でも PHP だと、この規模のコードをここまで徹底してクラスに分けることで逆に可読性や保守性を下げる場合もあるのでは……？ OCP適用例：DRY原則を守る

// Java の例（enum がパラメータを持てる） public enum Tax { TaxFree(0), ConsumptionTax(10),
private final int rate; private Tax(final int rate) { this.rate = rate; } public int amount(final int price) { return price * rate / 100; } }

// Java の例（enum でオーバーライド） public enum Tax { // 非課税
TaxFree { @Override public int amount(final int price) { return 0; } }, // 消費税・課税対象 ConsumptionTax { @Override public int amount(final int price) { return price * rate / 100; } }, public abstract int amount(final int price); }

// Scala の例 (sealed trait) sealed trait Tax { def
amount(price: Int): Int } // 非課税 case class TaxFree() extends Tax { override def amount(price: Int): Int = 0 } // 消費税・課税対象 case class ConsumptionTax() extends Tax { override def amount(price: Int): Int = price + (price * 0.1).toInt }

// Kotlin の例（sealed interface） sealed interface Tax { fun amount(price:
Int): Int } // 非課税 data class TaxFree : Tax { override fun amount(price: Int): Int = 0 } // 消費税・課税対象 data class ConsumptionTax : Tax { override fun amount(price: Int): Int = (price * 0.1).toInt() }

解消例（PHP向け妥協版）

$tax): int { return $this->price + $tax->compute($this->price); } } // 税率側に計算するメソッドを定義する enum Tax { ... public function compute(int $amount): int { return match ($this) { self::TaxFree => $amount, self::ConsumptionTax => $amount + (int)($amount * 1.1), self::ReducedConsumptionTax => $amount + (int)floor($amount * 1.08), }; } } 商品クラスは渡された税率のメソッドを呼び出すだけ

$tax): int { return $this->price + $tax->compute($this->price); } } // 税率側に計算するメソッドを定義する enum Tax { ... public function compute(int $amount): int { return match ($this) { self::TaxFree => $amount, self::ConsumptionTax => $amount + (int)($amount * 1.1), self::ReducedConsumptionTax => $amount + (int)floor($amount * 1.08), }; } } 税率側に列挙子ごとの処理を match 式等で記述

$tax): int { return $this->price + $tax->compute($this->price); } } // 税率側に計算するメソッドを定義する enum Tax { ... public function compute(int $amount): int { return match ($this) { self::TaxFree => $amount, self::ConsumptionTax => $amount + (int)($amount * 1.1), self::ReducedConsumptionTax => $amount + (int)floor($amount * 1.08), }; } } 常に列挙子を網羅するテストを書くこと！

開放閉鎖の原則：まとめ高い拡張性と保守性を両立するためコードの「修正」ではなく「追加」によって機能が拡張できるように設計しよう • ストラテジーパターンやDRY原則に沿った設計がポイント •
将来的な拡張が予想される部分で適用すると威力を発揮する例）消費税率、配送方法、支払方法、etc... • 「区分」「種類」等での if/switch/match が出てきたら OCP を適用できないか検討してみよう • PHP でやるときは可読性・保守性とのバランスも意識したい

3. Liskov Substitution Prinsiple リスコフの置換原則

LSP/リスコフの置換原則 “Functions that use pointers or references to base classes
must be able to use objects of derived classes without knowing it.” 意訳：とあるクラスを扱う関数は、その派生クラスについて知らずに扱うことができなくてはならない。

Photo: Kenneth C. Zirkel, CC BY-SA 3.0, via Wikimedia Commons
Barbara Liskov （1939.11 〜） • 米国で女性初の博士（Computer Science） • MIT教授（Computer Science） • 2008年にチューリング賞を受賞

リスコフの置換原則：より具体的に言うと？ • メソッドの事前条件を増やさない • メソッドの事後条件を減らさない • オブジェクトの不変条件を変えない • メソッドが投げる例外の種類を増やさない

例：こんなホテル予約サイトはイヤだ • ホテルAの場合：予約前に電話で確認が必要 • ホテルBの場合：予約後に電報を送らないと予約が完了しない • ホテルCの場合：当日行ってみたらホテルじゃなくてスパだった • ホテルDの場合：施設側の選り好みで予約不可の場合がある

例：こんなホテル予約サイトはイヤだ • ホテルAの場合：予約前に電話で確認が必要 ➡ 事前条件が増えている！ • ホテルBの場合：予約後に電報を送らないと予約が完了しない ➡ 事後条件が減っている！ •
ホテルCの場合：当日行ってみたらホテルじゃなくてスパだった ➡ 不変条件が変わっている！ • ホテルDの場合：施設側の選り好みで予約不可の場合がある ➡ 例外の種類が増えている！

例：こんなホテル予約サイトはイヤだ • ホテルAの場合：予約前に電話で確認が必要 ➡ 事前条件が増えている！ • ホテルBの場合：予約後に電報を送らないと予約が完了しない ➡ 事後条件が減っている！ •
ホテルCの場合：当日行ってみたらホテルじゃなくてスパだった ➡ 不変条件が変わっている！ • ホテルDの場合：施設側の選り好みで予約不可の場合がある ➡ 例外の種類が増えている！プログラミングも一緒だよね

メソッドの事前条件を増やさない

class FileStorage { public function store(string $src, string $dir, array
$options = []): void { // $src を $dir ディレクトリに保存する処理 // $options には保存に関するオプションが含まれる // $options が空でも問題なく動作する // ... } } class S3FileStorage extends FileStorage { public function store(string $src, string $dir, array $options = []): void { if (!isset($options['bucket']) || $options['bucket'] === '') { throw new InvalidArgumentException('Bucket name is required!!'); } // ... } } // FireStorage を使ってファイルを保存する関数 function storeFile(FileStorage $storage, string $src, string $dir): void { $storage->store($src, $dir); } storeFile(new FileStorage(), 'source.txt', 'awesome/dir/path'); // OK storeFile(new S3FileStorage(), 'source.txt', 'awesome/dir/path'); // ERROR!

$options = []): void { // $src を $dir ディレクトリに保存する処理 // $options には保存に関するオプションが含まれる // $options が空でも問題なく動作する // ... } } class S3FileStorage extends FileStorage { public function store(string $src, string $dir, array $options = []): void { if (!isset($options['bucket']) || $options['bucket'] === '') { throw new InvalidArgumentException('Bucket name is required!!'); } // ... } } // FireStorage を使ってファイルを保存する関数 function storeFile(FileStorage $storage, string $src, string $dir): void { $storage->store($src, $dir); } storeFile(new FileStorage(), 'source.txt', 'awesome/dir/path'); // OK storeFile(new S3FileStorage(), 'source.txt', 'awesome/dir/path'); // ERROR! S3 の場合は $options に bucket がないと例外を投げている

$options = []): void { // $src を $dir ディレクトリに保存する処理 // $options には保存に関するオプションが含まれる // $options が空でも問題なく動作する // ... } } class S3FileStorage extends FileStorage { public function store(string $src, string $dir, array $options = []): void { if (!isset($options['bucket']) || $options['bucket'] === '') { throw new InvalidArgumentException('Bucket name is required!!'); } // ... } } // FireStorage を使ってファイルを保存する関数 function storeFile(FileStorage $storage, string $src, string $dir): void { $storage->store($src, $dir); } storeFile(new FileStorage(), 'source.txt', 'awesome/dir/path'); // OK storeFile(new S3FileStorage(), 'source.txt', 'awesome/dir/path'); // ERROR! storeFile 関数は FileStorage の実装が何かを知らずに使いたい

$options = []): void { // $src を $dir ディレクトリに保存する処理 // $options には保存に関するオプションが含まれる // $options が空でも問題なく動作する // ... } } class S3FileStorage extends FileStorage { public function store(string $src, string $dir, array $options = []): void { if (!isset($options['bucket']) || $options['bucket'] === '') { throw new InvalidArgumentException('Bucket name is required!!'); } // ... } } // FireStorage を使ってファイルを保存する関数 function storeFile(FileStorage $storage, string $src, string $dir): void { $storage->store($src, $dir); } storeFile(new FileStorage(), 'source.txt', 'awesome/dir/path'); // OK storeFile(new S3FileStorage(), 'source.txt', 'awesome/dir/path'); // ERROR! FileStorage は $options を省略しても動く

$options = []): void { // $src を $dir ディレクトリに保存する処理 // $options には保存に関するオプションが含まれる // $options が空でも問題なく動作する // ... } } class S3FileStorage extends FileStorage { public function store(string $src, string $dir, array $options = []): void { if (!isset($options['bucket']) || $options['bucket'] === '') { throw new InvalidArgumentException('Bucket name is required!!'); } // ... } } // FireStorage を使ってファイルを保存する関数 function storeFile(FileStorage $storage, string $src, string $dir): void { $storage->store($src, $dir); } storeFile(new FileStorage(), 'source.txt', 'awesome/dir/path'); // OK storeFile(new S3FileStorage(), 'source.txt', 'awesome/dir/path'); // ERROR! S3FileStorage に差し替えると例外発生！

メソッドの事前条件を増やさないメソッドを呼び出す際に呼び出し元が満たすべき条件を増やさない • 入力の制約引数の型、引数のバリデーション条件 etc... • オブジェクト自身の状態事前に特定のメソッドを呼び出す必要がある etc...
• 外部リソースの状態トランザクションが開始している、商品の在庫がある etc...

メソッドの事前条件を増やさないメソッドを呼び出す際に呼び出し元が満たすべき条件を増やさない • 入力の制約引数の型、引数のバリデーション条件 etc... • オブジェクト自身の状態事前に特定のメソッドを呼び出す必要がある etc...
• 外部リソースの状態トランザクションが開始している、商品の在庫がある etc... Factory パターンや DI で解決できる場合もある

メソッドの事後条件を減らさない

class FileStorage { public function getFileInfo(string $path): array { return
[ 'size' => ..., 'created_at' => ..., 'permissions' => ..., ]; } } class S3FileStorage extends FileStorage { public function getFileInfo(string $path): array { // S3 にはファイルパーミッションがないので省略する return [ 'size' => ..., 'created_at' => ..., ]; } } function doSomething(FileStorage $storage, string $path): void { $info = $storage->getFileInfo($path); // permissions を使って何か処理をする } doSomething(new FileStorage(), '/path/to/file'); // OK doSomething(new S3FileStorage(), '/path/to/s3/file'); // Undefined array key "permissions" in ...

[ 'size' => ..., 'created_at' => ..., 'permissions' => ..., ]; } } class S3FileStorage extends FileStorage { public function getFileInfo(string $path): array { // S3 にはファイルパーミッションがないので省略する return [ 'size' => ..., 'created_at' => ..., ]; } } function doSomething(FileStorage $storage, string $path): void { $info = $storage->getFileInfo($path); // permissions を使って何か処理をする } doSomething(new FileStorage(), '/path/to/file'); // OK doSomething(new S3FileStorage(), '/path/to/s3/file'); // Undefined array key "permissions" in ... ファイルサイズ・作成日時・パーミッションを返す

[ 'size' => ..., 'created_at' => ..., 'permissions' => ..., ]; } } class S3FileStorage extends FileStorage { public function getFileInfo(string $path): array { // S3 にはファイルパーミッションがないので省略する return [ 'size' => ..., 'created_at' => ..., ]; } } function doSomething(FileStorage $storage, string $path): void { $info = $storage->getFileInfo($path); // permissions を使って何か処理をする } doSomething(new FileStorage(), '/path/to/file'); // OK doSomething(new S3FileStorage(), '/path/to/s3/file'); // Undefined array key "permissions" in ... S3 にはパーミッションがないから、と戻り値の要素を減らしている

[ 'size' => ..., 'created_at' => ..., 'permissions' => ..., ]; } } class S3FileStorage extends FileStorage { public function getFileInfo(string $path): array { // S3 にはファイルパーミッションがないので省略する return [ 'size' => ..., 'created_at' => ..., ]; } } function doSomething(FileStorage $storage, string $path): void { $info = $storage->getFileInfo($path); // permissions を使って何か処理をする } doSomething(new FileStorage(), '/path/to/file'); // OK doSomething(new S3FileStorage(), '/path/to/s3/file'); // Undefined array key "permissions" in ... doSomething 関数は FileStorage の実装が何かを知らずに使いたい

[ 'size' => ..., 'created_at' => ..., 'permissions' => ..., ]; } } class S3FileStorage extends FileStorage { public function getFileInfo(string $path): array { // S3 にはファイルパーミッションがないので省略する return [ 'size' => ..., 'created_at' => ..., ]; } } function doSomething(FileStorage $storage, string $path): void { $info = $storage->getFileInfo($path); // permissions を使って何か処理をする } doSomething(new FileStorage(), '/path/to/file'); // OK doSomething(new S3FileStorage(), '/path/to/s3/file'); // Undefined array key "permissions" in ... もちろん FileStorage を使えばちゃんと動く

[ 'size' => ..., 'created_at' => ..., 'permissions' => ..., ]; } } class S3FileStorage extends FileStorage { public function getFileInfo(string $path): array { // S3 にはファイルパーミッションがないので省略する return [ 'size' => ..., 'created_at' => ..., ]; } } function doSomething(FileStorage $storage, string $path): void { $info = $storage->getFileInfo($path); // permissions を使って何か処理をする } doSomething(new FileStorage(), '/path/to/file'); // OK doSomething(new S3FileStorage(), '/path/to/s3/file'); // Undefined array key "permissions" in ... S3FileStorage に差し替えるとエラーが発生！

メソッドの事後条件を減らさないメソッドの処理完了時に保証する状態や結果（約束）を守る • 戻り値戻り値の型や、その内容、範囲 etc... • オブジェクト自身の状態メソッド実行後にあるべきオブジェクトの状態 •
外部リソースの状態や副作用オブジェクトが永続化される、メールが送信される etc...

オブジェクトの不変条件を変えない

オブジェクトの不変条件を変えないオブジェクトが常に満たすべき条件・ルールを変えてはならない • オブジェクト自身の状態やメソッドの戻り値例1）$item->price は常に値を持ち、0以上である例2）$member->email の値は常にメールアドレスである例3）$date->getMonth() の戻り値は常に
1〜12 である

メソッドが投げる例外の種類を増やさない

メソッドが投げる例外の種類を増やさない呼び出し元が予期しない例外を投げてはならない • 文字通りの意味例）S3 実装では SDK が投げる AWSException をそのまま伝搬する
ちゃんと共通の例外で wrap してから投げよう

リスコフの置換原則：まとめ継承（インターフェースの実装を含む）時に守るべきルールを徹底することで、拡張しやすく、壊れにくい状態を維持しよう • クライアント（オブジェクトやメソッドを使う側）との約束を守る • コードの再利用目的での安易な継承は避ける • 違反しそうになったら委譲など継承以外の方法を検討する

4. Interface Segregation Prinsiple インターフェース分離の原則

ISP/インタフェース分離の原則 “Many client-specific interfaces are better than one general-purpose interface.”
意訳：汎用インターフェースが1つだけあるよりも、要求ごとに分離された複数のインターフェースがあった方がよい。

アンチパターン例

// リポジトリインターフェース interface Repository { public function lookup(int $id): Entity;
public function store(Entity $entity): void; public function remove(int $id): void; } 参照・保存・削除ができるリポジトリのインターフェース

public function store(Entity $entity): void; public function remove(int $id): void; } // 読み取り専用リポジトリ final readonly class ReadonlyItemRepository implements Repository { public function lookup(int $id): ReadonlyItem { // ... } public function store(Entity $entity): never { throw new BadMethodCallException('not supported'); } public function remove(int $id): never { throw new BadMethodCallException('not supported'); } } 読み取り専用のリポジトリが必要になった

public function store(Entity $entity): void; public function remove(int $id): void; } // 読み取り専用リポジトリ final readonly class ReadonlyItemRepository implements Repository { public function lookup(int $id): ReadonlyItem { // ... } public function store(Entity $entity): never { throw new BadMethodCallException('not supported'); } public function remove(int $id): never { throw new BadMethodCallException('not supported'); } } メソッドの定義が必要なので仕方なく例外を投げる……

解消例

// 読み取り可能なリポジトリのインターフェース interface ReadableRepository { public function lookup(int $id): Entity;
} // 書き込み可能なリポジトリのインターフェース interface WritableRepository { public function store(Entity $entity): void; public function remove(int $id): void; } // 一般的なリポジトリ final readonly class ItemRepository implements ReadableRepository, WritableRepository { public function lookup(int $id): Entity { // ... } public function store(Entity $entity): void { // ... } public function remove(int $id): void { // ... } } // 読み取り専用リポジトリ final readonly class ReadOnlyItemRepository implements ReadableRepository { public function lookup(int $id): Entity { // ... } }

} // 書き込み可能なリポジトリのインターフェース interface WritableRepository { public function store(Entity $entity): void; public function remove(int $id): void; } // 一般的なリポジトリ final readonly class ItemRepository implements ReadableRepository, WritableRepository { public function lookup(int $id): Entity { // ... } public function store(Entity $entity): void { // ... } public function remove(int $id): void { // ... } } // 読み取り専用リポジトリ final readonly class ReadOnlyItemRepository implements ReadableRepository { public function lookup(int $id): Entity { // ... } } 用途別に細かくインターフェースを定義する

} // 書き込み可能なリポジトリのインターフェース interface WritableRepository { public function store(Entity $entity): void; public function remove(int $id): void; } // 一般的なリポジトリ final readonly class ItemRepository implements ReadableRepository, WritableRepository { public function lookup(int $id): Entity { // ... } public function store(Entity $entity): void { // ... } public function remove(int $id): void { // ... } } // 読み取り専用リポジトリ final readonly class ReadOnlyItemRepository implements ReadableRepository { public function lookup(int $id): Entity { // ... } } 必要なインターフェースを複数実装する

} // 書き込み可能なリポジトリのインターフェース interface WritableRepository { public function store(Entity $entity): void; public function remove(int $id): void; } // 一般的なリポジトリ final readonly class ItemRepository implements ReadableRepository, WritableRepository { public function lookup(int $id): Entity { // ... } public function store(Entity $entity): void { // ... } public function remove(int $id): void { // ... } } // 読み取り専用リポジトリ final readonly class ReadOnlyItemRepository implements ReadableRepository { public function lookup(int $id): Entity { // ... } } 余分なメソッドの定義がなくなってスッキリ！

インターフェース分離の原則：まとめ全部入りの大きなインターフェースを1つだけ用意するのではなく、用途別の小さなインターフェースに分けて定義しよう • 余分な実装やテストを書かなくて済むようになる • テスト用のダミーを用意するのも楽になる • 割と後からでもどうにかなる
• 必要に応じて後から分割する戦略でもあまり困らない。序盤から無理に適用しなくてもいいのでは？

5. Dependency Inversion Prinsiple インターフェース分離の原則

DIP/依存性逆転の原則 “High-level modules should not import anything from low-level modules.
Both should depend on abstractions, not concretions.” 意訳：上位モジュールは下位からなにもインポートしてはならない。さらに上位・下位を問わず、実装ではなく抽象に依存すべきである。

• 上位モジュールは下位からなにもインポートしてはならない ➡ 上位（何をするのか＝ビジネスロジック・ドメインモデル）から　下位（どうやるのか＝インフラ層・WEB 境界など）に依存しない • さらに上位・下位を問わず、実装ではなく抽象に依存すべきである ➡
具体的な実装ではなく「何をしたいのか」という抽象化を行って　そこに依存する依存性逆転の原則：わかりやすく言うと？逆転云々はいったん忘れてもOK

• 関心の分離と疎結合化が促進され、タスクの分割や分業、単体テストがしやすい設計となる • フレームワークやライブラリ、外部 API の仕様やインフラ構成などの外部依存とビジネスロジックが分離されることで外部環境の変化に強
い設計となる依存性逆転の法則：なにがうれしいの？

• 依存性の注入（DI）コードから直接依存して new するのではなく、外部から依存を注入することで疎結合となり、関心が分離できる • 腐敗防止層の導入フレームワークやライブラリを直接呼び出すのではなく、使う側の関心
に合わせて腐敗防止層を導入し、技術的詳細の変化に対応しやすくする • Clean Architecture DIP の権化とも言えるアーキテクチャなので、クリーンアーキテクチャに沿うように設計すれば自然と DIP にも沿った設計になる（はず）依存性逆転の法則：どのように実現するの？

依存性逆転の原則：下位から上位へ依存する Database Adapters Use Cases Entity Gateway API Controller Web
Framework/Library

アンチパターン例

final readonly class FileUploadService { public function upload(UploadedFile $file): void
{ $client = new S3Client([ // S3 接続先などの設定 ... ]); $client->putObject([ // アップロードするファイルの設定 ... ]); } } ユーザーがアップロードしたファイルを保存する処理

final readonly class FileUploadService { public function upload(UploadedFile $file): void
{ $client = new S3Client([ // S3 接続先などの設定 ... ]); $client->putObject([ // アップロードするファイルの設定 ... ]); } } 技術的な詳細（S3）に直接依存してしまっている

final readonly class FileUploadService { public function __construct( private S3ClientInterface
$s3Client ) {} public function upload(UploadedFile $file): void { $this->s3Client->putObject([ // アップロードするファイルの設定 ... ]); } } S3Client を DI で注入すればOK？

final readonly class FileUploadService { public function __construct( private S3ClientInterface
$s3Client ) {} public function upload(UploadedFile $file): void { $this->s3Client->putObject([ // アップロードするファイルの設定 ... ]); } } FileUploadService はアップロードされたファイルを永続化したいだけ、保存先には興味がない

解消例

interface FileStorageInterface { public function upload(UploadedFile $file): void; } final
readonly class S3FileStorage implements FileStorageInterface { public function __construct( private S3ClientInterface $s3Client ) {} public function upload(UploadedFile $file): void { // S3 へファイルをアップロードする処理 ... } } final readonly class FileUploadService { public function __construct( private FileStorageInterface $storage ) {} public function upload(UploadedFile $file): void { $this->storage->upload($file); // その他アップロードに関する処理 ... } }

readonly class S3FileStorage implements FileStorageInterface { public function __construct( private S3ClientInterface $s3Client ) {} public function upload(UploadedFile $file): void { // S3 へファイルをアップロードする処理 ... } } final readonly class FileUploadService { public function __construct( private FileStorageInterface $storage ) {} public function upload(UploadedFile $file): void { $this->storage->upload($file); // その他アップロードに関する処理 ... } } ファイルを保存したい、というビジネス側の都合でインターフェースを定義する

readonly class S3FileStorage implements FileStorageInterface { public function __construct( private S3ClientInterface $s3Client ) {} public function upload(UploadedFile $file): void { // S3 へファイルをアップロードする処理 ... } } final readonly class FileUploadService { public function __construct( private FileStorageInterface $storage ) {} public function upload(UploadedFile $file): void { $this->storage->upload($file); // その他アップロードに関する処理 ... } } ビジネス側の都合に合わせて技術的な詳細を実装する

readonly class S3FileStorage implements FileStorageInterface { public function __construct( private S3ClientInterface $s3Client ) {} public function upload(UploadedFile $file): void { // S3 へファイルをアップロードする処理 ... } } final readonly class FileUploadService { public function __construct( private FileStorageInterface $storage ) {} public function upload(UploadedFile $file): void { $this->storage->upload($file); // その他アップロードに関する処理 ... } } ビジネスロジックから技術的な詳細への依存が消えた

依存性逆転の原則：まとめ上位（抽象的で安定したビジネスのコア）でインターフェースを定義し、下位（技術的な詳細）が依存する形にすることで変化に強い設計にしよう • 開発の分業や単体テストが楽になる • フレームワーク・ライブラリ・外部 API・インフラ構成など外部環境の変更に対応しやすくなる
• 依存性の注入（DI）や腐敗防止層などを活用する • 開発初期から全部真面目にやりすぎるとコストが高すぎるかも？

まとめ • SOLID原則を守って設計することで高い安全性・安定性・保守性・可読性・変更容易性・テスト容易性を手に入れることができる • ただし、あらゆる文脈で常に正解となる銀の弾丸ではない • SOLID原則を守ることは目的ではなく、価値を得るための手段 •
SOLID原則を知らずに技術的負債を生むのではなく、理解した上でビジネス上の価値を生むために取捨選択することが重要

THANK YOU!!

最後に宣伝

We are Hiring!!

PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference J...

PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference Japan 2025

More Decks by shogogg

Other Decks in Technology

Featured

Transcript