単一責任の原則(SRP)
単一責務の原則とは
- 「クラスを変更する理由は一つ以上存在してはならない」という原則
- 役割(責任) ＝ 変更理由
適用方法
例：メソッドに「データの読取」「解析」「検証」「ログの出力」「データベースへの挿入」という5つの責務が存在する場合
①明瞭性を高めるため、1責務1メソッドに分割する。
明瞭性を高めると、コードの読みやすさが向上する。
この場合、3メソッド(データの読取、解析(解析＋検証)、データベースの挿入)に分割される。
②抽象化を高めるため、責務にインターフェイスを適用する。
抽象化を高めることで、ソフトウェア変更の要求に対応しやすくなる。
この場合、データの読取、処理、データの格納という大きなインターフェイスに分割する。
(データの読取が、ストリームではなく、Webデータから受取に変わっても対応できるよう)
(入力データのフォーマットが変わり、新しいフィールドが追加されても対応できるよう)
シーケンスを流すクラスにコンストラクタ経由でインタフェースを継承したインスタンスを渡してやると、クラスの付替えが可能になる。
注意
- 仮に2つの役割が必ず同時に変更されるようなケースではわざわざ分離する必要はない。
- 設計が不必要に複雑になってしまうため。
- ビジネスルールと、データベースなど永続性のあるシステムを包含してはいけない。ビジネスルールは頻繁に変化するし、永続性のあるシステムはビジネスルールの場合と全く違う理由で変化する場合があるため。
結論
- 明瞭性を高めるため、1責務1メソッドに分割すること
- 明瞭性の高いコードの書き方はリーダブルコード参照
- 抽象化を高めるため、責務毎にインタフェースを分割すること とりあえずは上記を意識すれば良いと思われる。 クラスの分割については、実践UMLのGRASPパターンに委ねる。。
参考：
アジャイルソフトウェア開発の奥義
