一つのモノには一つのことだけやらせる
いわゆる単一責任の原則 (SRP)。一つのモノの責務・役割は一つにする。「一つのモノに変更が入る理由は一つにする」ともいえる。
なぜそうするのか
ある一つのモノが複数の理由で変更されうるとなると、それらの整合性を取るのが大変になるから。
単一責任のメリット
- そのクラスやメソッドの責任が単一で明確になっていれば、用途や使いどころがハッキリする。システム全体・各部分ともに見通しが良くなり、分かりやすくなる
- 単一責務に絞ることで、そのクラスやメソッドが依存するモノが減らせる。依存するモノが減らせると、変更に強くなる
- 人間の仕事を細分化・分業化した方が効率が良くなるのと同じ。一人で全部やろうとするとアタフタするが、コレだけやると決めてあれば、責任の所在もハッキリするし、作業の質も上がる。コードでも同じことが言える
単一責任を採用しないデメリット
- 「そのクラスやメソッドがやること」が増え、「何をインプットに何がアウトプットされるのか」が分かりづらくなる
- ある理由による変更を加える時、対象の箇所が依存するモノにも影響が出やすく、変更時の調整がしづらくなる
一つのモノが抱える責任、依存関係が増えていくと、保守しづらくなる。
一つのモノにやらせすぎない
- 概念化・抽象化 (オブジェクト指向・ドメイン駆動設計) が正しくできない人は、一つのモノに多くのことをやらせすぎる傾向にある
- 「メッセージ処理サービスクラス」だとかいって、画面表示する全てのメッセージを定数で持っていたり、エラーメッセージの整形出力処理を持っていたり → いわゆる「神クラス」と呼ばれるアンチパターン
- 「1メソッドの行数は100行以内、1クラスの行数は1000行以内」などといった規則は、単に見通しが悪くなることを避けるためのコーディングルールとして展開されがちだが、単一責務の原則を守っていればまずこれ以上の行数にはならないだろう、という「数値化できる指標」としても有用
- 文書を書く場合も、一つの文書、一つの章に詰め込み過ぎない
- 「〜〜について」というタイトルや見出しにしてしまうと、何をどこまで書くか迷う。見出しによって執筆する「範囲」を定めることが大事