PHP の SOLID 原則とそれがコード品質をどのように向上させるかを理解する-PHPチュートリアル-php.cn

Understanding the SOLID Principles in PHP and How They Improve Code Quality

PHP の SOLID 原則とは何ですか?

SOLID 原則は、ソフトウェア開発者がより保守性、柔軟性、スケーラブルなアプリケーションを作成するのに役立つ 5 つの設計原則のセットです。これは、ソフトウェアが適切に構造化され、拡張が容易で、エラーが発生しにくいことを保証するために、オブジェクト指向プログラミング (OOP) で広く使用されています。これらの原則は、開発者がコードの重複を回避し、複雑さを軽減し、読みやすさを向上させるのに役立つため、PHP アプリケーションを作成する場合に特に有益です。

SOLID 原則は Robert C. Martin (Uncle Bob) によって導入され、高品質で保守可能なコードを作成するための青写真を提供します。 SOLID の頭字語の各文字は、次の 5 つの原則のいずれかを表します。

S - 単一責任原則 (SRP)
O - オープン/クローズ原則 (OCP)
L - リスコフ置換原理 (LSP)
私 - インターフェース分離原則 (ISP)
D - 依存関係逆転原理 (DIP)

各原則を詳しく調べて、それがコードの品質をどのように向上させるかを理解しましょう。

1.単一責任原則 (SRP)

定義: クラスが変更する理由は 1 つだけである必要があります。つまり、クラスの責任または仕事は 1 つだけである必要があります。クラスが複数の責任を引き受けると、保守と変更が難しくなります。

PHP の例:

// Bad Example: A class handling multiple responsibilities
class UserManager {
    public function createUser($data) {
        // Logic to create user
    }

    public function sendEmail($user) {
        // Logic to send email
    }
}

ログイン後にコピー

この例では、UserManager クラスがユーザーの作成と電子メールの送信の両方を担当しますが、これは単一責任の原則に違反します。

改良例:

// Good Example: Separate responsibilities into different classes
class UserManager {
    public function createUser($data) {
        // Logic to create user
    }
}

class EmailService {
    public function sendEmail($user) {
        // Logic to send email
    }
}

ログイン後にコピー

SRP がコード品質を向上させる理由:

保守が容易: 電子メールの機能が変更された場合、ユーザー管理ロジック全体ではなく、EmailService クラスのみを変更する必要があります。
より良いコード構成: 懸念事項を分離することで、コードがよりモジュール化され、理解とテストが容易になります。

2.オープン/クローズ原則 (OCP)

定義: ソフトウェアエンティティ (クラス、モジュール、関数など) は拡張に対してオープンである必要がありますが、変更に対してはクローズされている必要があります。これは、既存のコードを変更せずにクラスの動作を拡張できる必要があることを意味します。

PHP の例:

// Bad Example: A class handling multiple responsibilities
class UserManager {
    public function createUser($data) {
        // Logic to create user
    }

    public function sendEmail($user) {
        // Logic to send email
    }
}

ログイン後にコピー

新しい動作 (割引など) を処理するために Order クラスを変更する代わりに、元のコードに手を加えずにクラスを拡張できます。

改良例:

// Good Example: Separate responsibilities into different classes
class UserManager {
    public function createUser($data) {
        // Logic to create user
    }
}

class EmailService {
    public function sendEmail($user) {
        // Logic to send email
    }
}

ログイン後にコピー

OCP がコード品質を向上させる理由:

既存の機能を壊すリスクの軽減: コアロジックを変更するのではなく動作を拡張することで、アプリケーションの他の部分を壊すリスクが最小限に抑えられます。
柔軟性の向上: 既存のコードベースを変更せずに、新しい機能を簡単に追加できます。

3.リスコフ置換原理 (LSP)

定義: スーパークラスのオブジェクトは、プログラムの正確さに影響を与えることなく、そのサブクラスのオブジェクトと置き換え可能である必要があります。この原則により、プログラムの望ましいプロパティを変更することなく、派生クラスを基本クラスに置き換えることができます。

PHP の例:

// Bad Example: Modifying existing class to add functionality
class Order {
    public function calculateTotal($items) {
        $total = 0;
        foreach ($items as $item) {
            $total += $item['price'];
        }
        return $total;
    }
}

class DiscountOrder extends Order {
    public function calculateTotal($items) {
        $total = parent::calculateTotal($items);
        $total -= 10;  // Apply discount
        return $total;
    }
}

ログイン後にコピー

この例では、fly メソッドはダチョウには適用できないため、Bird オブジェクトを Ostrich オブジェクトに置き換えるとプログラムが中断されます。

改良例:

// Good Example: Using interfaces or abstract classes for extension
interface DiscountStrategy {
    public function applyDiscount($total);
}

class NoDiscount implements DiscountStrategy {
    public function applyDiscount($total) {
        return $total;
    }
}

class TenPercentDiscount implements DiscountStrategy {
    public function applyDiscount($total) {
        return $total * 0.9;
    }
}

class Order {
    private $discountStrategy;

    public function __construct(DiscountStrategy $discountStrategy) {
        $this->discountStrategy = $discountStrategy;
    }

    public function calculateTotal($items) {
        $total = 0;
        foreach ($items as $item) {
            $total += $item['price'];
        }
        return $this->discountStrategy->applyDiscount($total);
    }
}

ログイン後にコピー

LSP がコード品質を向上させる理由:

プログラムの整合性を維持します: クラスを置き換えても、システムの予期される動作が壊れたり変更されたりしてはなりません。
コードをより予測可能かつ再利用可能にします: LSP を正しく実装すると、サブクラスを基本クラスと互換的に使用できるようになります。

4.インターフェース分離原則 (ISP)

定義: クライアントは、使用しないインターフェースに強制的に依存すべきではありません。言い換えれば、1 つの大規模な汎用インターフェイスよりも、小規模で特定のインターフェイスをいくつか用意した方が良いということです。

PHP の例:

// Bad Example: Violating Liskov Substitution
class Bird {
    public function fly() {
        // Flying logic
    }
}

class Ostrich extends Bird {
    public function fly() {
        throw new Exception("Ostriches can't fly!");
    }
}

ログイン後にコピー

この例では、ロボットクラスは、それに関係のない Eat メソッドの実装を強制されています。

改良例:

// Good Example: Respecting Liskov Substitution
class Bird {
    public function move() {
        // General movement logic
    }
}

class Sparrow extends Bird {
    public function move() {
        // Flying logic for sparrow
    }
}

class Ostrich extends Bird {
    public function move() {
        // Walking logic for ostrich
    }
}

ログイン後にコピー

ISP がコード品質を向上させる理由:

より焦点を絞ったインターフェイス: クライアントは不要なメソッドの実装を強制されず、よりクリーンでより焦点を絞ったコードが得られます。
保守が簡単: インターフェイスが小さいほど、保守と変更が簡単です。

5.依存性反転原理 (DIP)

定義: 高レベルのモジュールは低レベルのモジュールに依存すべきではありません。どちらも抽象化 (インターフェイスなど) に依存する必要があります。さらに、抽象化は詳細に依存すべきではありません。詳細は抽象化に依存する必要があります。

PHP の例:

// Bad Example: A class handling multiple responsibilities
class UserManager {
    public function createUser($data) {
        // Logic to create user
    }

    public function sendEmail($user) {
        // Logic to send email
    }
}

ログイン後にコピー

ここで、UserService は Database に直接依存していますが、高レベルのロジックを低レベルの実装に結び付けるため、DIP に違反します。

改良例:

// Good Example: Separate responsibilities into different classes
class UserManager {
    public function createUser($data) {
        // Logic to create user
    }
}

class EmailService {
    public function sendEmail($user) {
        // Logic to send email
    }
}

ログイン後にコピー

DIP がコード品質を向上させる理由: