【Java初心者向け】SOLID原則の「S(単一責任の原則)」をやさしく解説!
こんにちは。ゆうせいです。
今回は、オブジェクト指向設計の基本中の基本とも言える「SOLID原則」の中から、S=単一責任の原則(Single Responsibility Principle)を取り上げて、Javaのコードを使って初心者にも分かりやすく解説していきます!
SOLID原則とは?
まず簡単に背景から。
SOLID原則とは、以下の5つの設計原則の頭文字を取ったものです。
項目 | 名前 | 日本語訳 |
---|---|---|
S | Single Responsibility Principle | 単一責任の原則 |
O | Open/Closed Principle | 開放・閉鎖原則 |
L | Liskov Substitution Principle | リスコフの置換原則 |
I | Interface Segregation Principle | インターフェース分離の原則 |
D | Dependency 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のインターフェース設計
コードがシンプルであることは、強さです。ぜひ新人エンジニアの皆さんも意識してみてくださいね!
セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク
投稿者プロフィール
