2020-05-05 11:38:43

単一責任原則を調べる_No1

単一責任原則を復習しました。感覚的には「アクターが異なる状況で、同じ処理を重複しないように1箇所に作成するとバグになる可能性があるから別々に作成しよう。」という感じでした。

「データを関数から切り離す」と良いらしいですが、切り離したところで同じ関数を参照していたら同じようにバグるのでは？という疑問を持ちました。良くわからないので持ったままです。

書籍「clean architecture 達人に学ぶソフトウェアの構造と設計」には次のように定義されています

モジュールはたったひとつのアクターに対して責務を負うべきである。

引用: clean architecture 達人に学ぶソフトウェアの構造と設計

ここでの「モジュール」、「アクター」は次のように説明されています。

• モジュール
  • ソースファイル
• アクター
  • 変更を望む人たちをひとまとめにしたグループ

書籍にはアクターが決まっている状態で例題が記載されていますが、実践ではアクターを見分けること自体の難易度が高いように感じました。

単一責任原則を守るには、まずソフトウェアに関わるアクターを調べていく必要がありそうです。でないとモジュール定義が出来ないので。

どのくらいの粒度でアクターを定義していくかが難しい。運営会社、営業会社、コンサル会社、エンドユーザー...などソフトウェアには様々な人が関わってくると思います。営業会社が変更を望むと、それは運営会社経由で依頼が来ると思います。この場合、運営会社と営業会社は1つのアクターとして扱っても良い気がしますが、運営会社だけが変更を望む場合はまた別の1つのアクターとして扱うのかな。それとも、営業会社が変更を望む場合は、営業会社を１つのアクターとして扱うのかな。

いつの日にか身体に馴染むことを期待しています。

参考資料

• clean architecture 達人に学ぶソフトウェアの構造と設計