without meaning

組み込み系SIerの技術メモ。

単一責任の原則(SRP)

単一責務の原則とは


  • 「クラスを変更する理由は一つ以上存在してはならない」という原則
    • 役割(責任) = 変更理由

適用方法


例:メソッドに「データの読取」「解析」「検証」「ログの出力」「データベースへの挿入」という5つの責務が存在する場合

①明瞭性を高めるため、1責務1メソッドに分割する。
 明瞭性を高めると、コードの読みやすさが向上する。
 この場合、3メソッド(データの読取、解析(解析+検証)、データベースの挿入)に分割される。

②抽象化を高めるため、責務にインターフェイスを適用する。
 抽象化を高めることで、ソフトウェア変更の要求に対応しやすくなる。
 この場合、データの読取、処理、データの格納という大きなインターフェイスに分割する。
 (データの読取が、ストリームではなく、Webデータから受取に変わっても対応できるよう)
 (入力データのフォーマットが変わり、新しいフィールドが追加されても対応できるよう)

シーケンスを流すクラスにコンストラクタ経由でインタフェースを継承したインスタンスを渡してやると、クラスの付替えが可能になる。

注意


  • 仮に2つの役割が必ず同時に変更されるようなケースではわざわざ分離する必要はない。
    • 設計が不必要に複雑になってしまうため。
  • ビジネスルールと、データベースなど永続性のあるシステムを包含してはいけない。ビジネスルールは頻繁に変化するし、永続性のあるシステムはビジネスルールの場合と全く違う理由で変化する場合があるため。

結論

  • 明瞭性を高めるため、1責務1メソッドに分割すること
    • 明瞭性の高いコードの書き方はリーダブルコード参照
  • 抽象化を高めるため、責務毎にインタフェースを分割すること とりあえずは上記を意識すれば良いと思われる。 クラスの分割については、実践UMLのGRASPパターンに委ねる。。

参考:
アジャイルソフトウェア開発の奥義

C#実践開発手法