DIPとは？依存性逆転の原則を簡単解説

依存性逆転の原則（DIP）とは？

依存性逆転の原則（DIP: Dependency Inversion Principle）は、ソフトウェア設計におけるSOLID原則の一つで、「高水準モジュール（主要なビジネスロジック）は低水準モジュール（具体的な実装）に直接依存せず、両者とも抽象化されたもの（インターフェースや抽象クラス）に依存すべき」という考え方です。

詳しくいうと

高水準モジュールと低水準モジュールの関係
- 高水準モジュール：ビジネスロジックやアプリケーションの核となる部分（例：注文処理、在庫管理）。
- 低水準モジュール：具体的な処理を行う部分（例：データベースアクセス、外部API呼び出し）。
通常、高水準モジュールは低水準モジュールを利用して動作しますが、この依存関係を直接にしてしまうと、低水準モジュールの変更が高水準モジュールに影響を与えるという問題が発生します。

依存性逆転の基本ルール
依存性逆転の原則は、この問題を解決するために以下のルールを提唱します
- 高水準モジュールが低水準モジュールに直接依存しないこと。
- 両者が「抽象化されたインターフェースや抽象クラス」に依存すること。
これにより、低水準モジュールを変更しても高水準モジュールに影響を与えない柔軟な設計が実現します。

「抽象化」に依存する設計とは？
抽象化されたインターフェースや抽象クラスを設け、高水準モジュールと低水準モジュールの間に共通の契約（Contract）を定義します。
- 高水準モジュールは、この契約を利用する。
- 低水準モジュールは、この契約を実装する。
これにより、高水準モジュールは「具体的な実装」ではなく「抽象的な契約」に依存する形となります。

簡単に言うと

高水準モジュールは、具体的なクラス（具象クラス）ではなく、抽象的なインターフェースや抽象クラスに依存するべきです。
これにより、システムが柔軟になり、新しい機能の追加や既存機能の変更が簡単になります。

考えが生まれた背景

ソフトウェア設計において、以下のような課題が頻繁に発生していました：

コードの修正が広範囲に及ぶ

高水準モジュールが特定の低水準モジュールに直接依存している場合、低水準モジュールに変更が加わると、それを利用している高水準モジュールにも修正が必要になります。
例えば、通知システムがメール送信機能に依存している場合、通知方法をSMSやプッシュ通知に変更すると、高水準モジュール全体を見直す必要が生じます。

拡張性が低い

低水準モジュールに依存した設計では、新しい機能やモジュールを追加する際、既存のコードに手を加える必要があるため、変更の影響範囲が広がりがちです。
これにより、新しいモジュールの導入が難しく、システムの柔軟性が損なわれます。

テストが困難

高水準モジュールが具体的な低水準モジュール（例えば、データベースや外部API呼び出し）に依存している場合、テスト用のモック（テスト用の代替オブジェクト）を作成しにくくなります。
その結果、単体テストが難しくなり、開発やデバッグにかかる時間が増加します。

DIPのメリット

柔軟性が高い

高水準モジュールが抽象化（インターフェースや抽象クラス）に依存しているため、新しい低水準モジュール（例：プッシュ通知や外部API）を追加しても、高水準モジュールを修正する必要がありません。
これにより、異なる要件や仕様変更に対しても柔軟に対応できます。

テストが簡単

高水準モジュールが具体的な実装ではなく抽象化されたインターフェースに依存しているため、テスト用のモックオブジェクトを簡単に作成可能です。

実際のデータベースや外部APIに依存しない単体テストを効率的に実施できます。
テスト対象部分に集中できるため、テストの信頼性と速度が向上します。

拡張性が向上

低水準モジュールが抽象化を実装する形で設計されているため、システムを安全に拡張できます。

新しい機能を追加しても、高水準モジュールのコードに手を加える必要がないため、既存の動作を壊すリスクを最小限に抑えられます。
これにより、長期運用が必要なシステムでもスムーズに機能追加が可能です。

変更の影響を最小化

低水準モジュールが変更された場合でも、高水準モジュールはその変更に直接依存していないため、変更の影響範囲が限定的です。

高水準モジュールが影響を受けにくいため、システム全体の安定性が向上します。
これにより、保守作業が効率化し、開発コストやリスクが削減されます。

具体的な例

NGな例：具象クラスに依存している場合

以下は、通知（Notification）を送信するシステムの例です。通知を「メール」で送る場合に特化した設計になっています。

Java

class EmailService {
    public void sendEmail(String message) {
        System.out.println("Sending email: " + message);
    }
}

class Notification {
    private EmailService emailService;

    public Notification() {
        emailService = new EmailService(); // 具体的な実装に依存している
    }

    public void send(String message) {
        emailService.sendEmail(message);
    }
}

問題点：

Notification クラスが EmailService に直接依存しているため、通知方法を変更する（例：SMSやプッシュ通知を追加する）場合、Notification クラスの修正が必要になります。

OKな例：抽象化に依存する設計

以下は、依存性逆転の原則を適用した設計です。

Java

// 抽象化されたインターフェース
interface MessageService {
    void sendMessage(String message);
}

// 具体的な実装：メール送信
class EmailService implements MessageService {
    public void sendMessage(String message) {
        System.out.println("Sending email: " + message);
    }
}

// 具体的な実装：SMS送信
class SmsService implements MessageService {
    public void sendMessage(String message) {
        System.out.println("Sending SMS: " + message);
    }
}

// 高水準モジュール
class Notification {
    private MessageService messageService;

    // コンストラクタで依存性を注入
    public Notification(MessageService messageService) {
        this.messageService = messageService;
    }

    public void send(String message) {
        messageService.sendMessage(message);
    }
}

使い方：

Java

public class Main {
    public static void main(String[] args) {
        MessageService emailService = new EmailService();
        Notification notification = new Notification(emailService);
        notification.send("Hello via Email!");

        MessageService smsService = new SmsService();
        notification = new Notification(smsService);
        notification.send("Hello via SMS!");
    }
}