【Java初心者向け】SOLID原則の「S(単一責任の原則)」をやさしく解説!

こんにちは。ゆうせいです。
今回は、オブジェクト指向設計の基本中の基本とも言える「SOLID原則」の中から、S=単一責任の原則(Single Responsibility Principle)を取り上げて、Javaのコードを使って初心者にも分かりやすく解説していきます!


SOLID原則とは?

まず簡単に背景から。
SOLID原則とは、以下の5つの設計原則の頭文字を取ったものです。

項目名前日本語訳
SSingle Responsibility Principle単一責任の原則
OOpen/Closed Principle開放・閉鎖原則
LLiskov Substitution Principleリスコフの置換原則
IInterface Segregation Principleインターフェース分離の原則
DDependency Inversion Principle依存関係逆転の原則

それではさっそく、Sの内容を詳しく見ていきましょう!


単一責任の原則(SRP)とは?

一言でいうと?

「クラスは、たった一つの理由でしか変更されてはならない」というルールです。

どういう意味?

あるクラスが複数の責任(役割)を持ってしまうと、それぞれの責任に応じて変更が発生する可能性が高まり、変更に弱く、壊れやすいコードになります。

例えてみよう!

「料理人が掃除も買い物も接客も全部やってるレストラン」を想像してください。
それぞれの業務でルールが変わったら、その人がすべてに対応しなきゃいけなくなります。
それよりも、料理人は料理に専念、接客はホール担当に任せる
これが単一責任の考え方です!


悪い例(単一責任に違反)

public class ReportManager {
    public String generateReport() {
        return "レポート内容";
    }

    public void saveToFile(String content) {
        // ファイルに保存
        System.out.println("ファイルに保存しました: " + content);
    }

    public void sendByEmail(String content) {
        // メールで送信
        System.out.println("メール送信しました: " + content);
    }
}

このクラス、何をしているかわかりますか?

  • レポートの生成
  • ファイル保存
  • メール送信

やることが多すぎます!
「変更理由が3つ」もある=単一責任違反です。


良い例(単一責任を守る)

以下のように、それぞれの責任を専用のクラスに分離します。

// レポートを生成する責任
public class ReportGenerator {
    public String generate() {
        return "レポート内容";
    }
}

// ファイルに保存する責任
public class FileSaver {
    public void save(String content) {
        System.out.println("ファイルに保存しました: " + content);
    }
}

// メールで送信する責任
public class EmailSender {
    public void send(String content) {
        System.out.println("メール送信しました: " + content);
    }
}

そして、まとめ役がいると便利です。

public class ReportManager {
    private final ReportGenerator generator = new ReportGenerator();
    private final FileSaver saver = new FileSaver();
    private final EmailSender sender = new EmailSender();

    public void processReport() {
        String content = generator.generate();
        saver.save(content);
        sender.send(content);
    }
}

これなら、たとえば「ファイル保存の仕様が変わる」場合でも、FileSaverだけを修正すれば済みます


メリットと注意点

メリット

  • クラスが小さくなり、読みやすくなる
  • 変更の影響範囲が小さくなり、壊れにくい
  • テストがしやすくなる

注意点(やりすぎ注意)

  • クラスを分けすぎると、ファイル数が増えて混乱することも
  • あくまで「意味のある責任」で分けることが重要です

単一責任原則に関するチェックリスト

チェックポイント確認方法
クラスの名前が曖昧じゃないか?「Manager」や「Helper」など曖昧な名前は注意!
変更理由が複数ないか?「このクラスは何をするときに変わるか?」を考える
機能が増えてメソッドが肥大していないか?1クラス20行超えたら一度見直してみよう

まとめと次のステップ

単一責任の原則は、SOLIDの中でも最も基本であり、他の原則の土台になります。
新人エンジニアの方は、最初のうちは「1クラス=1つのことをする」という意識を持つだけでも大きな進歩です!

次に学ぶべきこと:

  • SOLIDの「O」=開放・閉鎖原則(Open/Closed Principle)
  • リファクタリング技法(Extract Class, Extract Method)
  • Javaのインターフェース設計

コードがシンプルであることは、強さです。ぜひ新人エンジニアの皆さんも意識してみてくださいね!

セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク

投稿者プロフィール

山崎講師
山崎講師代表取締役
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します!
この記事に間違い等ありましたらぜひお知らせください。