Zenn
😸

依存性逆転の原則 (Dependency Inversion Principle, DIP)

2025/01/01に公開
Ruby
solid
依存性逆転の原則
dependencyinversio
tech

1. どんなもの？

依存性逆転の原則（Dependency Inversion Principle, DIP）は、高レベルモジュール（ビジネスロジック）は低レベルモジュール（具体的な実装）に依存してはならず、両者とも抽象に依存すべきという設計原則です。

簡単に言えば、「直接的に具体的な実装に依存せず、抽象化されたインターフェースを通じて依存関係を管理する」ことで、柔軟で保守性の高い設計を実現します。

例えば、Railsアプリケーションで通知システムを設計する場合、メール通知やSMS通知の具体的な実装に依存せず、共通のインターフェースを通じて動作させる設計がこの原則に従います。

2. 通常の実装方法と比べてどこがすごいの？

通常の方法

具体的なクラスに直接依存すると、変更が発生した際に影響範囲が広がり、柔軟性が低下します。

class UserNotifier
  def notify(user, message)
    EmailNotification.new.send(user, message)
  end
end

class EmailNotification
  def send(user, message)
    puts "Sending email to #{user.email}: #{message}"
  end
end

notifier = UserNotifier.new
notifier.notify(user, "Welcome!")
  • 課題:
    • UserNotifierがEmailNotificationに直接依存しているため、新しい通知方法（例: SMS）を追加する場合、UserNotifierのコードを変更する必要がある。
    • 拡張性が低く、変更が困難。

DIPに基づいた方法

抽象クラスまたはインターフェースを導入することで、依存性を逆転させます。

class UserNotifier
  def initialize(notification_service)
    @notification_service = notification_service
  end

  def notify(user, message)
    @notification_service.send_notification(user, message)
  end
end

class EmailNotification
  def send_notification(user, message)
    puts "Sending email to #{user.email}: #{message}"
  end
end

class SmsNotification
  def send_notification(user, message)
    puts "Sending SMS to #{user.phone}: #{message}"
  end
end

email_notifier = UserNotifier.new(EmailNotification.new)
sms_notifier = UserNotifier.new(SmsNotification.new)

email_notifier.notify(user, "Welcome!") # => Sending email to user@example.com: Welcome!
sms_notifier.notify(user, "Welcome!")   # => Sending SMS to 123456789: Welcome!
  • 利点:
    • UserNotifierはEmailNotificationやSmsNotificationに直接依存せず、柔軟に新しい通知方法を追加可能。
    • 依存関係を簡単に変更できるため、テストや保守が容易。

3. 技術や手法の"キモ"はどこにある？

  1. 依存性の抽象化

    • 具体的な実装に依存するのではなく、抽象クラスやインターフェースに依存します。

  2. コンストラクタインジェクション

    • 依存するオブジェクトをコンストラクタを通じて注入（DI: Dependency Injection）することで、依存関係を外部から制御します。

  3. 柔軟性の向上

    • 依存関係を抽象化することで、実装の変更や追加が容易になります。
      • 具体的な実装（例: EmailNotification や SmsNotification）に直接依存するのではなく、それらの共通したインターフェースや抽象クラス（例: notification_service）を通じて依存関係を管理することを指します。

4. 実装例

例: Railsのログ機能

以下の例では、異なるログライブラリ（例: ログファイル、標準出力）を柔軟に使用できます。

class LoggerService
  def initialize(logger)
    @logger = logger
  end

  def log(message)
    @logger.write(message)
  end
end

class FileLogger
  def write(message)
    puts "Writing to file: #{message}"
  end
end

class ConsoleLogger
  def write(message)
    puts "Logging to console: #{message}"
  end
end

file_logger = LoggerService.new(FileLogger.new)
console_logger = LoggerService.new(ConsoleLogger.new)

file_logger.log("File log message")   # => Writing to file: File log message
console_logger.log("Console log message") # => Logging to console: Console log message
  • 実装ポイント:
    • 異なるログ出力先を柔軟に選択可能。

5. 議論はあるか？

メリット

  • 高レベルモジュールと低レベルモジュールが独立し、変更や拡張が容易。
  • 依存関係を簡単に変更できるため、テストやモック作成がしやすい。

デメリット

  • 抽象クラスやインターフェースを作成するコストが増える。
  • 小規模なプロジェクトでは過剰設計になる場合がある。

議論

依存性逆転の原則は、特に大規模なシステムで効果を発揮します。ただし、小規模なプロジェクトでは実装が複雑になりすぎる可能性があるため、適用範囲を慎重に見極めることが重要です。

高レベルモジュールと低レベルモジュール

1. 高レベルモジュール (High-level Module)

概要

  • システム全体の振る舞いやビジネスロジックを司る部分。
  • ユーザーが期待する動作や、アプリケーションの主要な機能を実現するコード。
  • 具体的な実装の詳細（データベースや外部APIの仕様など）に依存せず、抽象的な操作や処理を記述します。

特徴

  1. 抽象度が高い:
    • 具体的なデータの処理方法や通信手段には関与せず、「何をすべきか」を記述します。
  2. システムの中心的な役割:
    • アプリケーションのコア部分を担い、外部モジュールやサービスを利用して動作します。

例

以下の例では、UserNotifierクラスが高レベルモジュールです。
このクラスは通知を送るというビジネスロジックを定義していますが、具体的な通知方法（メールやSMS）には依存していません。

class UserNotifier
  def initialize(notification_service)
    @notification_service = notification_service
  end

  def notify(user, message)
    @notification_service.send_notification(user, message)
  end
end

2. 低レベルモジュール (Low-level Module)

概要

  • 高レベルモジュールが指示する具体的な動作を実現する部分。
  • データベースの操作、ファイルの読み書き、APIの呼び出しなど、詳細な処理を実装します。

特徴

  1. 抽象度が低い:
    • 特定の技術や仕様に依存した処理を記述します。
  2. インフラやデータ操作に近い部分:
    • 実際のデータ操作や外部システムとの連携を担います。

例

以下の例では、EmailNotificationとSmsNotificationが低レベルモジュールです。それぞれが具体的な通知方法（メールやSMS）を実装しています。

class EmailNotification
  def send_notification(user, message)
    puts "Sending email to #{user.email}: #{message}"
  end
end

class SmsNotification
  def send_notification(user, message)
    puts "Sending SMS to #{user.phone}: #{message}"
  end
end

3. 高レベルモジュールと低レベルモジュールの関係

高レベルモジュールは、低レベルモジュールの機能を利用して動作します。しかし、直接的に低レベルモジュールに依存してしまうと、変更や拡張が難しくなります。この問題を解決するために、「依存性逆転の原則 (DIP)」を適用します。

直接依存している場合（悪い例） 

class UserNotifier
  def notify(user, message)
    EmailNotification.new.send_notification(user, message)
  end
end
  • 問題点:
    • UserNotifierはEmailNotificationに直接依存しています。
    • 新しい通知方法（例: SMS）を追加する場合、UserNotifierを変更する必要があります。

依存性逆転の原則を適用した場合（良い例） 

class UserNotifier
  def initialize(notification_service)
    @notification_service = notification_service
  end

  def notify(user, message)
    @notification_service.send_notification(user, message)
  end
end

class EmailNotification
  def send_notification(user, message)
    puts "Sending email to #{user.email}: #{message}"
  end
end

class SmsNotification
  def send_notification(user, message)
    puts "Sending SMS to #{user.phone}: #{message}"
  end
end

# 使用例
email_notifier = UserNotifier.new(EmailNotification.new)
sms_notifier = UserNotifier.new(SmsNotification.new)

email_notifier.notify(user, "Welcome!") # => Sending email to user@example.com: Welcome!
sms_notifier.notify(user, "Welcome!")  # => Sending SMS to 123456789: Welcome!
  • 改善点:
    • UserNotifierはEmailNotificationやSmsNotificationに直接依存せず、抽象的なインターフェース（共通のメソッドsend_notification）に依存しています。
    • 新しい通知方法を追加しても、UserNotifierを変更する必要がありません。

4. 高レベルモジュールと低レベルモジュールの違い

特徴 高レベルモジュール 低レベルモジュール
役割 ビジネスロジックや主要な機能を司る部分 データ処理や具体的な実装を担当する部分
抽象度 高い 低い
依存関係 抽象化された低レベルモジュールに依存 高レベルモジュールから指示を受けて動作
変更の影響 低レベルモジュールの実装に依存しないため小さい 高レベルモジュールの指示に応じて変更が必要になる
例（通知システム） 通知の送信を指示する（UserNotifier） メール送信やSMS送信を実装する（EmailNotification）

5. なぜこの区別が重要なのか？

高レベルモジュールが直接低レベルモジュールに依存すると、以下の問題が生じます：

  • 低レベルモジュールの変更が高レベルモジュールに影響を及ぼす。
  • 新しい実装を追加する際、既存コードの変更が必要になる。

このため、「高レベルモジュールと低レベルモジュールの間に抽象を置く」ことで、両者を疎結合にし、保守性や拡張性を向上させることが重要です。

6. まとめ

依存性逆転の原則（DIP）は、高レベルモジュールと低レベルモジュールを分離し、抽象に依存する設計を目指す原則です。

この原則を守ることで、コードの保守性と拡張性が向上し、柔軟で堅牢なシステムを構築できます。

GitHubで編集を提案

Discussion