1. はじめに
「ちょっと修正しただけなのに、別のところが壊れた…」
そんな経験はありませんか？😢
それ、1つのクラス（または関数）がやりすぎているのが原因かもしれません。
この記事では、SOLID原則の1つ目
単一責任の原則（Single Responsibility Principle / SRP） を
初心者向けに「考え方」から解説します。
📌 TypeScriptのコードも使いますが、
理解のための補助として最小限にしています。
2. この記事でわかること
- 単一責任の原則とは何か
- なぜ「責任を1つにする」必要があるのか
- SRPを意識すると何が嬉しいのか
- TypeScriptでの簡単な例
3. 単一責任の原則とは？
一言でいうと、こうです。
「1つのクラスや関数などは、1つの役割（責任）だけを持つべき」
…と言われても、ちょっと抽象的ですよね 🤔
なので、まずは「なぜ必要なのか」から考えてみましょう。
4. そもそも「責任が多い」と何が困る？
次のようなクラスを想像してみてください。
class UserService {
createUser(name: string) {
// ユーザーを作成する
}
sendWelcomeEmail() {
// 登録完了メールを送信する
}
saveToFile() {
// ユーザー情報をファイルに保存する
}
}
このクラス、何をしているでしょうか？
- ユーザー作成
- メール送信
- ファイル保存
……ちょっとやりすぎですよね 😅
何が問題なのか？
このクラスには、変更される理由がいくつもあります。
-
メールの仕様が変わった
-
保存先がDBに変わった
-
ユーザー作成のルールが変わった
📌 どれか1つが変わるだけで、このクラスを修正する必要がある
これが続くと、
- 修正が怖い
- テストが大変
- バグが入りやすい
という状態になります。
5. SRPの本当の意味
単一責任の原則で大事なのは、
「変更される理由は1つだけか？」
という視点です。
- 「メソッドが1つだけ」
- 「ファイルが小さい」
という意味ではありません ⚠️
改善してみる
では、役割ごとに分けてみましょう。
class UserCreator {
create(name: string) {
// ユーザーを作成する
}
}
class EmailService {
sendWelcome() {
// 登録完了メールを送信する
}
}
class UserRepository {
save() {
// ユーザー情報を保存する
}
}
それぞれのクラスは、
- 何をするクラスか
- 何が変わったら修正が必要か
がはっきりしています 👍
6. SRPを意識すると何が嬉しい？
- 修正の影響範囲が小さくなる
- クラスの名前を見ただけで役割がわかる
- テストが書きやすくなる
- チーム開発でも理解しやすい
📌 「読む人にやさしいコード」 になるのが最大のメリットです。
7. まとめ
- 単一責任の原則は「責任を1つにしよう」という考え方
- ポイントは「変更理由が1つかどうか」
最初から完璧に守らなくてOK
迷ったら 「このクラス、何担当？」 と自分に聞く
次回予告
次回はオープン・クローズドの原則 を解説します。
「新機能を追加するたびに、if文が増えていく…」
そんな悩みを解決する考え方です 💡
ぜひ続けて読んでみてください！
8. おわりに
最後まで読んでいただきありがとうございました！🎉
よろしければ他の記事もご覧頂けるとすごくうれしいです。
👍 いいね / 💬 コメントいただけると励みになります！