単一責任の原則

単一責任の原則 (たんいつせきにんのげんそく、英: single-responsibility principle) は、プログラミングに関する原則であり、モジュール、クラスまたは関数は、単一の機能について責任を持ち、その機能をカプセル化するべきであるという原則である。モジュール、クラスまたは関数が提供するサービスは、その責任と一致している必要がある^[1]。

単一責任の原則は、ロバート・C・マーティン（英語版）によって定義された。この原則について、彼は、「クラスを変更する理由は、ひとつだけであるべきである」^[1] と表し、「変更する理由」に関して、「この原則は、人についてのものである」と述べ^[2]、アクターについてのものであると補足した^[3]。

歴史

単一責任の原則は、ロバート・C・マーティンの記事『The Principles of OOD』でオブジェクト指向設計の原則のひとつとして紹介され^[4]、2003年に出版された『アジャイルソフトウェア開発の奥義』^[5]で有名になった。マーティンは、単一責任の原則がトム・デマルコ『構造化分析とシステム仕様』^[6]およびM・ペイジ・ジョーンズ『構造化システム設計への実践的ガイド』^[7]における凝集度に基づいていると述べた。2014年、マーティンは、「変更する理由」という言葉を明確にするために、『The Single Responsibility Principle』と題したブログ記事を投稿した。

例

報告書モジュールのクラス図の例

マーティンは、責任とは変更する理由であるとし、モジュールを変更する理由は、ひとつだけであるべきであると定めた。モジュールを変更する理由をひとつだけにする目的は、モジュールの堅牢性を高めることである。

例えば、報告書を作成して、描画するようなモジュールを想定する。まず、レポートの内容を変更したい場合に、このモジュールを変更する必要がある。また、レポートの形式を変更したい場合にも、このモジュールを変更する必要がある。さらに、これらのふたつの変更は、それぞれ異なるアクターによるものである。よって、このモジュールは、変更する理由、すなわち責任を複数持っており、これらを結合する設計は、単一責任の原則に反している。仮に、レポートの内容の変更に伴って、報告書を作成する実装を修正する場合、報告書を描画する処理にも影響が及ぶ可能性がある。