🎯

単一責任の原則 (Single Responsibility Principle, SRP)

に公開
Ruby
solid
単一責任の原則
singleresponsibili
tech

1. どんなもの？

単一責任の原則（Single Responsibility Principle, SRP）は、クラスが1つの責任だけを持つべきだという設計原則です。

この原則に従うことで、クラスは1つの目的に集中し、コードの保守性や再利用性を向上させることができます。

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

通常の方法

例えば、「ユーザー情報の管理」と「メール送信」に関する実装を進めているとします。
複数の責任(「ユーザー情報の管理」と「メール送信」)を1つのクラスに詰め込むと、コードが煩雑になり、変更や拡張時に問題が発生します。

class User
  attr_accessor :name, :email

  def initialize(name, email)
    @name = name
    @name = email
  end

  def send_welcome_email
    puts "Sending welcome email to #{email}"
  end
end

user = User.new("Alice", "alice@example.com")
user.send_welcome_email
  • 課題:
    • ユーザー情報の管理とメール送信が1つのクラスに詰め込まれている。
    • メール送信ロジックを変更すると、ユーザークラス自体を変更することになる。
    • ユーザー情報が使いたいだけなのに、メール送信機能も付いてくる。
    • 1つのクラスで複数機能を持っているため、複数メンバーでの開発の際にコンフリクトを起こしやすくなる。

SRPに基づいた方法

単一責任の原則を適用すると、1つのクラスが1つの責任のみを持つように設計されます。

class User
  attr_accessor :name, :email

  def initialize(name, email)
    @name = name
    @name = email
  end
end

class EmailService
  def send_welcome_email(user)
    puts "Sending welcome email to #{user.email}"
  end
end

user = User.new("Alice", "alice@example.com")
email_service = EmailService.new
email_service.send_welcome_email(user)
  • 利点:
    • ユーザー情報の管理とメール送信の責任が分離され、クラスがシンプルになる。
    • メール送信ロジックを変更しても、ユーザークラスには影響を与えない。
    • 逆にユーザークラスを変更しても、メール送信ロジックには影響を与えない。
    • 複数メンバーで開発する際もクラスが分離されているため、コンフリクトを回避しやすい。

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

  1. 責任の分離

    • 1つのクラスが1つの目的に集中することで、コードの可読性と再利用性が向上します。

  2. 変更理由の分離

    • クラスが持つ責任が1つであれば、そのクラスを変更する理由も1つに絞られます。

  3. 設計の柔軟性

    • 単一責任の原則を守ることで、クラス間の依存関係が減り、設計が柔軟になります。

4. 実装例

Railsモデルとサービスオブジェクトの分離

モデルの責任をデータ管理のみに限定し、ビジネスロジックをサービスオブジェクトに分離。

class User < ApplicationRecord
end

class UserService
  def initialize(user)
    @user = user
  end

  def activate
    @user.update(active: true)
    NotificationService.new.send_activation_email(@user)
  end
end

class NotificationService
  def send_activation_email(user)
    puts "Sending activation email to #{user.email}"
  end
end

user = User.find(1)
user_service = UserService.new(user)
user_service.activate
  • ポイント:
    • Userクラスの責任がデータ管理のみに限定され、それ以外の処理(例では activate化)が切り出されまとまっているので、コードが簡潔になる。

5. 議論はあるか？

メリット

  • クラスがシンプルになり、理解しやすくなる。
  • 責任が分離されているため、影響範囲が小さく、変更が容易。

デメリット

  • 責任を分離することで、クラスやファイルの数が増える。
  • 小規模なプロジェクトでは、複雑さを招く場合がある。

議論

単一責任の原則は、コードの可読性と保守性を大幅に向上させる強力な原則ですが、適用しすぎると過剰設計になるリスクもあります。シンプルさを保ちながら適用することが重要です。

6. まとめ

単一責任の原則（SRP）は、1つのクラスが1つの責任だけを持つべきという設計原則です。
Railsでは、モデルとビジネスロジックの分離、サービスオブジェクトやメールテンプレートの分離など、さまざまな場面で適用されています。

この原則を守ることで、コードの保守性と拡張性が向上し、変更に強いシステムを構築できます。

GitHubで編集を提案

Discussion