初心者こそ知っておきたい「単一責任の原則」

プログラミングを始めたばかりの頃って、
「動けばいいや！」と勢いでコードを書きがちですよね。

でも、あとで読み返すと、

• どこを直せばいいのか分からない
• 1行変えたら別の場所が壊れた
• クラスが巨大化して手がつけられない

こんな経験、ありませんか。

そんな“未来の自分を助ける”ための考え方として、
単一責任の原則（Single Responsibility Principle / SRP）
というものがあります。

---

単一責任の原則って何？

ざっくり言うと、

「1つのクラス（またはメソッド）は、1つの責任だけを持つべき」

という考え方です。

もっと噛み砕くと、

• 1つのクラスにいろんな役割を詰め込まない
• 1つのメソッドに“あれもこれも”やらせない
• 1つの変更理由しか持たないようにする

ということです。

---

なんでそんなに大事なの？

初心者のうちは「別に1クラスで全部書いても動くし…」と思うかもしれません。
でも、アプリが大きくなるほど、SRPを守っているかどうかで難易度が全然違います。

SRPを守ると起きる良いこと

• 修正がしやすい
  どこを直せばいいかが明確になる。

• バグが減る
  影響範囲が小さくなるので壊れにくい。

• テストしやすい
  役割が分かれていると単体テストが簡単。

• 再利用しやすい
  “1つのことだけやる部品”は使い回しやすい。

逆に、SRPを無視すると、

• クラスが肥大化して“神クラス”になる
• 修正のたびに別の場所が壊れる
• テストが書けない
• そもそも読む気が起きない

という地獄が待っています。

---

具体例を見てみよう

❌ 悪い例：1つのクラスに全部詰め込む

public class UserService
{
    public void Register(string name, string email)
    {
        // 入力チェック
        if (string.IsNullOrWhiteSpace(name) || string.IsNullOrWhiteSpace(email))
        {
            throw new ArgumentException("Invalid input");
        }

        // DB保存
        SaveToDatabase(name, email);

        // メール送信
        SendMail(email, "登録ありがとう！");
    }

    private void SaveToDatabase(string name, string email)
    {
        // DB保存処理（仮）
    }

    private void SendMail(string email, string message)
    {
        // メール送信処理（仮）
    }
}

このクラスは、

• 入力チェック
• DB保存
• メール送信

という3つの責任を持っています。

これが積み重なると、クラスがどんどん巨大化していきます。

---

⭕ 良い例：責任ごとに分ける

public class UserValidator
{
    public void Validate(string name, string email)
    {
        if (string.IsNullOrWhiteSpace(name) || string.IsNullOrWhiteSpace(email))
        {
            throw new ArgumentException("Invalid input");
        }
    }
}

public class UserRepository
{
    public void Save(string name, string email)
    {
        // DB保存処理（仮）
    }
}

public class Mailer
{
    public void SendWelcome(string email)
    {
        // メール送信処理（仮）
    }
}

public class UserService
{
    private readonly UserValidator _validator = new();
    private readonly UserRepository _repository = new();
    private readonly Mailer _mailer = new();

    public void Register(string name, string email)
    {
        _validator.Validate(name, email);
        _repository.Save(name, email);
        _mailer.SendWelcome(email);
    }
}

こうすると、

• 入力チェックを変えたい → UserValidator だけ触ればOK
• DBを変えたい → UserRepository だけ触ればOK
• メール文面を変えたい → Mailer だけ触ればOK

と、修正ポイントが明確になります。

---

「分けすぎじゃない？」と思ったあなたへ

初心者の方からよく聞くのが、

「こんなに細かく分ける必要あるの？」

という疑問です。

正直、最初は“分けすぎ”くらいでちょうどいいです。
慣れてくると、どこまで分けるべきか自然と分かるようになります。

大事なのは、

• 1つのクラスが複数の理由で変更される状態を避けること
• 役割を明確にして、未来の自分が困らないようにすること

この2つです。

---

まとめ

• 単一責任の原則は「1つのクラスは1つのことだけやる」という考え方
• コードが読みやすく、修正しやすく、バグが減る
• 最初は“分けすぎ”くらいでOK
• 未来の自分を助けるための習慣だと思って取り入れてみると良い

---