単一責任の原則
単一責任の原則 (たんいつせきにんのげんそく、英: single-responsibility principle) は、プログラミングに関する原則であり、モジュール、クラスまたは関数は、単一の機能について責任を持ち、その機能をカプセル化するべきであるという原則である。モジュール、クラスまたは関数が提供するサービスは、その責任と一致している必要がある[1]。
単一責任の原則は、ロバート・C・マーティンによって定義された。この原則について、彼は、「クラスを変更する理由は、ひとつだけであるべきである」[1] と表し、「変更する理由」に関して、「この原則は、人についてのものである」と述べ[2]、アクターについてのものであると補足した[3]。
歴史
単一責任の原則は、ロバート・C・マーティンの記事『The Principles of OOD』でオブジェクト指向設計の原則のひとつとして紹介され[4]、2003年に出版された『アジャイルソフトウェア開発の奥義』[5]で有名になった。マーティンは、単一責任の原則がトム・デマルコ『構造化分析とシステム仕様』[6]およびM・ペイジ・ジョーンズ『構造化システム設計への実践的ガイド』[7]における凝集度に基づいていると述べた。2014年、マーティンは、「変更する理由」という言葉を明確にするために、『The Single Responsibility Principle』と題したブログ記事を投稿した。
例
マーティンは、責任とは変更する理由であるとし、モジュールを変更する理由は、ひとつだけであるべきであると定めた。モジュールを変更する理由をひとつだけにする目的は、モジュールの堅牢性を高めることである。
例えば、報告書を作成して、描画するようなモジュールを想定する。まず、レポートの内容を変更したい場合に、このモジュールを変更する必要がある。また、レポートの形式を変更したい場合にも、このモジュールを変更する必要がある。さらに、これらのふたつの変更は、それぞれ異なるアクターによるものである。よって、このモジュールは、変更する理由、すなわち責任を複数持っており、これらを結合する設計は、単一責任の原則に反している。仮に、レポートの内容の変更に伴って、報告書を作成する実装を修正する場合、報告書を描画する処理にも影響が及ぶ可能性がある。
出典
- ^ a b Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. p. 95. ISBN 978-0135974445 2022年7月10日閲覧。
- ^ Martin, Robert C. (2014年). “The Single Responsibility Principle”. The Clean Code Blog. 2022年7月10日閲覧。
- ^ Robert C. Martin (2018). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall. ISBN 978-0-13-449416-6
- ^ Martin, Robert C. (2005年). “The Principles of OOD”. butunclebob.com. 2022年7月10日閲覧。
- ^ Martin 2003, pp. 95–98
- ^ DeMarco, Tom. (1979). Structured Analysis and System Specification. Prentice Hall. ISBN 0-13-854380-1
- ^ Page-Jones, Meilir (1988). The Practical Guide to Structured Systems Design. Yourdon Press Computing Series. p. 82. ISBN 978-8120314825
関連項目
- Single-responsibility principleのページへのリンク
