初心者こそ知っておきたい「単一責任の原則」 | TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発が進むにつれ、1つのクラスにバリデーション、データ永続化、外部通知などの複数の役割が混在する「神クラス」が発生する。これにより、一部の修正が予期せぬ箇所に影響を及ぼす副作用が生じ、テストの困難さやコードの解読不能といった技術負債を招く。
// Approach
クラスの役割を「変更の理由」に基づいて分離する。具体的には、入力チェック、データベース操作、メール送信といった個別の責務を独立したクラスへと抽出し、それらを協調させることで、各コンポーネントの役割を明確化する設計手法を採る。
// Result
修正時の影響範囲が局所化され、バグの混入リスクが低減する。また、各クラスが単一の機能に特化することで、単体テストの記述が容易になり、他のモジュールへの再利用性も向上する。これにより、長期的なメンテナンスコストの抑制が可能となる。
Senior Engineer Insight
> SRPの遵守は、大規模システムにおける変更コストの抑制と、デプロイ時のリスク管理において不可欠な規律である。責務を分離することで、コンポーネント間の結合度が下がり、並行開発や自動テストの効率が劇的に向上する。ただし、現場においては「分割の粒度」が常に課題となる。過度な分割は、クラス間の依存関係を複雑化させ、コードの全体像を把握しにくくする。重要なのは、単なる機能の切り出しではなく、ドメインモデルの境界に基づいた「変更の理由」の特定である。設計者は、常に「この変更はどのビジネスルールに起因するか」を問い続ける必要がある。