単一責任原則についての読書メモ
はじめに
エンジニアとしてコードと書いていると、設計についてあまり考えずに進めてしまうことがよくあります。しかし、コードの質を高めるためには設計の指針が必要だと感じました。
そこで、よく耳にするSOLID原則の一つである 単一責任原則 について学びたいと思い、いくつかの本をまとめて読んでみました。
単一責任原則とは
いくつかの本を読む中で、単一責任原則（Single Responsibility Principle, SRP）について学びました。ソフトウェアのモジュール（クラスや関数など）は「たった一つの理由」で変更されるべきだという原則です。この原則により、コードの可読性や保守性が向上するとのことです。
読む以前のざっくりとした印象は関数やメソッドに一つのことだけをやらせるのだと思っていました。
読んでいく中で勘違いしてたことがわかりました。
Clean Architecture
Clean Architecture では次のように述べられています。
モジュールを変更する理由はたったひとつだけであるべきである
モジュールはたった1つのアクターに対して責務を負うべきである
81ページ
ここでの アクター はユーザーやステークホルダーのことを指します。つまり、ソフトウェアの変更理由は特定のユーザーやステークホルダーに対してのみ責務を負うべきで、複数のアクターをまたがるような変更理由を持つべきではないということです。
レガシーコードとどう付き合うか
次に、 レガシーコードとどう付き合うか では次のように述べられています。
1つのモジュールが担う役割は1つであるべき
72ページ
この本では、 役割 という言葉を使っており、異なる役割を持つものは分けるべきだとしています。
例えば、ECサイトの価格取得モジュールで割引処理が混ざっていると、価格を取得するだけのシンプルな処理が複雑化してしまいます。これを避けるために、役割ごとに関数を分けて責務を明確にすることが重要だと述べています。
良いコード/悪いコードで学ぶ設計入門
最後に、 良いコード/悪いコードで学ぶ設計入門 では次のように述べられています。
クラスが担う責任は、たった一つにするべき
148ページ
日常生活の例えとして、過度な借金生活が自身の責任になることが示されていました。
ソフトウェアにおいても同様に、フロントエンドの表示やデータベース処理など、関心ごとに責任を明確に分けることが重要だと。
自分の所感
単一責任原則を読んでみて、以下のように理解しました。
- あるコードの変更理由は業務上のコンテキストによるべきで、変更理由は一つに限定するべき
- ユーザーやステークホルダーからみたコンテキストが変更理由であり、その理由が複数ある場合は責務範囲が不明確になっているため、設計を見直す必要がある
実際にコードを書くときや修正するときに、コンテキストマップのようなものが事前にあると、責務範囲がイメージしやすくなって結果的に保守性の高いコードを書くことができると感じました。
Discussion