この記事は私が「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだ際の備忘録です。
本記事を読んで興味を持たれたら是非読んでみてください。
本記事では、参考書籍にて語られている「単一責任の原則」に関わる部分についてまとめています。
今回から扱うSOLID原則はモジュールの設計方針を示すものですので、事前にモジュールの定義を述べておきます。
モジュールは、いくつかの関数や構造体をまとめた集合のことです。
多くの言語では一つのソースファイルが一つのモジュールと扱われます。
Pythonではソースファイルがモジュールに当たると公式ドキュメントで述べられています。(Python チュートリアル 6. モジュール)
「単一責任の原則」は「モジュールを変更する理由は一つだけであるべき」という原則です。
モジュールのふるまいを変えることになる理由は様々あります。
Webサービスであれば「ユーザに新しい機能を提供するため」や「管理者が見られる情報を追加するため」など、
人事管理システムであれば「人事部が閲覧できる情報を変更するため」や「経理部が見る給与の計算方法を変更するため」などです。
この「ユーザ」や「管理者」、「人事部」や「経理部」などの、ソフトウェアの変更を望むグループは「アクター」と呼ばれています。
「単一責任の原則」を詳細に述べると、「一つのモジュールについて変更を望むアクターは一つのみであるべき」という原則になります。
「単一責任の原則」と混同されやすいため、「関数は一つのことを行うべき」という原則についても述べておきます。
関数を設計する際の原則に「関数は一つのことを行うべき」という原則があります。
この原則は巨大な関数のリファクタリングなど、関数レベルの設計時に用いられます。
「単一責任の原則」とは設計対象と内容が異なります。
「単一責任の原則」を違反している場合、複数のアクターへ責任を負っているモジュールがあることになります。
このようなモジュールが、あるアクターによって変更を求められた場合、その変更の影響は他のアクターにも及ぶことになります。
変更して欲しいアクターとそうでないアクターが同時に発生することになりやすく、変更時に考慮すべき範囲が広くなります。
「単一責任の原則」を守れば影響を受けるアクターも一つのため、影響範囲を抑えることができます。
ここまで読んでいただきありがとうございます。
次回は10月に、「SOLID原則」の一つである「オープン・クローズドの原則」について書く予定です。
入会申込
ログイン
