コンテンツにスキップ

単一責任の原則

出典: フリー百科事典『ウィキペディア(Wikipedia)』

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

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

歴史

[編集]

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

[編集]
報告書モジュールのクラス図の例

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

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

出典

[編集]
  1. ^ a b Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. p. 95. ISBN 978-0135974445. https://books.google.com/books?id=0HYhAQAAIAAJ 2022年7月10日閲覧。 
  2. ^ Martin, Robert C. (2014年). “The Single Responsibility Principle”. The Clean Code Blog. 2022年7月10日閲覧。
  3. ^ Robert C. Martin (2018). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall. ISBN 978-0-13-449416-6. https://books.google.com/books?id=8ngAkAEACAAJ 
  4. ^ Martin, Robert C. (2005年). “The Principles of OOD”. butunclebob.com. 2022年7月10日閲覧。
  5. ^ Martin 2003, pp. 95–98
  6. ^ DeMarco, Tom. (1979). Structured Analysis and System Specification. Prentice Hall. ISBN 0-13-854380-1. https://archive.org/details/structuredanalys0000dema 
  7. ^ Page-Jones, Meilir (1988). The Practical Guide to Structured Systems Design. Yourdon Press Computing Series. p. 82. ISBN 978-8120314825 

関連項目

[編集]