「SOLID」の版間の差分
削除された内容 追加された内容
ce 文章整理・一部CO・引用文をblockquoteで表示・引用文の翻訳例をTemplate:翻訳で表示 |
Wikiwikiweb (会話 | 投稿記録) m 人名を修正。 |
||
| (3人の利用者による、間の5版が非表示) | |||
| 1行目: | 1行目: | ||
| ⚫ | |||
{{SOLID (オブジェクト指向設計)}} |
|||
| ⚫ | |||
この五つの原則は、アメリカのソフトウェア技術者{{仮リンク|ロバート・C・マーティン|en|Robert C. Martin|label=}}が提唱していた数々の設計原則の中からチョイスされたものである。マーティンが提唱していた原則は、例えば2000年に発表されたレポート |
この五つの原則は、アメリカのソフトウェア技術者{{仮リンク|ロバート・C・マーティン|en|Robert C. Martin|label=}}が提唱していた数々の設計原則の中からチョイスされたものである。マーティンが提唱していた原則は、例えば2000年に発表されたレポート『Design Principles and Design Patterns』<ref name="martin-design-principles">{{Cite web|url=http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf|title=Design Principles and Design Patterns|author=Robert C. Martin|website=objectmentor.com|accessdate=2009-01-14|archiveurl=https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf|archivedate=6 September 2015|date=2000}}</ref>の中で紹介されている<ref name="ub-old-web-solid">{{Cite web|url=http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod|title=Principles Of OOD|author=[[Robert C. Martin]]|website=butunclebob.com|accessdate=2014-07-17}}</ref><ref name="ub-solid">{{Cite web|url=https://sites.google.com/site/unclebobconsultingllc/getting-a-solid-start|title=Getting a SOLID start|author=Robert C. Martin|website=objectmentor.com|accessdate=2013-08-19}}</ref><ref name="metz-presentation-2009">{{Cite web|url=https://www.youtube.com/watch?v=v-2yFMzxqwU|title=SOLID Object-Oriented Design|author=[[Sandi Metz]]|accessdate=2019-08-13|date=May 2009}} Talk given at the 2009 Gotham [[Ruby]] Conference.</ref>。そのうち五原則を'''SOLID'''という語呂合わせの頭字語にして普及させたのは、ソフトウェア技術者マイケル・フェザーズであり、2004年以降に広く知られるようになった<ref>{{Cite book|last=Fenton|first=Steve|title=Pro TypeScript: Application-Scale JavaScript Development|year=2017|isbn=9781484232491|page=108|url=https://books.google.co.uk/books?id=ZEtADwAAQBAJ&pg=PA108}}</ref>。SOLIDは[[オブジェクト指向設計]]由来であるが、[[アジャイルソフトウェア開発]]や{{仮リンク|適応的ソフトウェア開発|en|adaptive software development|label=}}といった方法論の哲学にもなっている。 |
||
== 五つの原則 == |
== 五つの原則 == |
||
SOLIDは、次の5つの原則からなる。 |
|||
* [[単一責任の原則|単一責任の原則 ('''s'''ingle-responsibility principle)]] |
|||
* [[開放/閉鎖原則|開放閉鎖の原則（'''o'''pen/closed principle）]] |
|||
| ⚫ | <blockquote> |
||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
=== 単一責任の原則 (single-responsibility principle) === |
|||
{{翻訳|変更するための理由が、一つのクラスに対して一つ以上あってはならない}}</blockquote>これは「every class should have only one responsibility.」{{翻訳|各クラスはそれぞれ一つだけの責務を持つべきである}}とも言い換えられる。ここでの責務とは提供機能と同義である。 |
|||
<blockquote>There should never be more than one reason for a class to change.<ref>{{Cite web|title=Single Responsibility Principle|url=http://www.objectmentor.com/resources/articles/srp.pdf|archiveurl=https://web.archive.org/web/20150202200348/http://www.objectmentor.com/resources/articles/srp.pdf|archivedate=1 June 2015|website=objectmentor.com|accessdate=2015-09-05|publisher=}}</ref>{{翻訳|変更するための理由が、一つのクラスに対して一つ以上あってはならない}}</blockquote>これは、every class should have only one responsibility.{{翻訳|各クラスはそれぞれ一つだけの責務を持つべきである}}とも言い換えられる。ここでの責務とは提供機能と同義である。この原則は、clientに特定の機能を提供する役割（role）役者（actor）としてのserviceの[[クラス (コンピュータ)|クラス]]に焦点を当てている。 |
|||
| ⚫ | |||
この原則は、役割（role）役者（actor）としての[[クラス (コンピュータ)|クラス]]に焦点を当てており、clientから見たserviceが対象である。 |
|||
=== 開放閉鎖の原則（open/closed principle） === |
|||
| ⚫ | |||
| ⚫ | <blockquote>software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.<ref>{{Cite web|title=Open/Closed Principle|url=http://www.objectmentor.com/resources/articles/ocp.pdf|archiveurl=https://web.archive.org/web/20150905081105/http://www.objectmentor.com/resources/articles/ocp.pdf|archivedate=5 September 2015|website=objectmentor.com|accessdate=2015-09-05|publisher=}}</ref>{{翻訳|ソフトウェアの実体（クラス、モジュール、関数など）は、拡張に対して開かれているべきであり、修正に対して閉じていなければならない}}</blockquote> |
||
この原則下のinterfaceはその構成が不変になり、serviceは構成の変化が許される。serviceの構成変化は、[[継承 (プログラミング)|継承]]による[[サブクラス (計算機科学)|サブクラス]]定義でなされるのが普通である。 |
|||
=== |
=== リスコフの置換原則（Liskov substitution principle） === |
||
<blockquote> |
<blockquote>Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.<ref>{{Cite web|title=Liskov Substitution Principle|url=http://www.objectmentor.com/resources/articles/lsp.pdf|archiveurl=https://web.archive.org/web/20150905081111/http://www.objectmentor.com/resources/articles/lsp.pdf|archivedate=5 September 2015|website=objectmentor.com|accessdate=2015-09-05|publisher=}}</ref>{{翻訳|ある基底クラスへのポインタないし参照を扱っている関数群は、その派生クラスのオブジェクトの詳細を知らなくても扱えるようにしなければならない}}</blockquote>この原則下のclientは、一つのinterfaceを通して、様々なserviceクラスを利用することになる。 |
||
=== インターフェース分離の原則 (Interface segregation principle) === |
|||
{{翻訳|ソフトウェアの実体（クラス、モジュール、関数など）は、拡張に対して開かれているべきであり、変更に対して閉じていなければならない}}</blockquote> |
|||
| ⚫ | <blockquote>Many client-specific interfaces are better than one general-purpose interface.<ref>{{Cite web|title=Interface Segregation Principle|url=http://www.objectmentor.com/resources/articles/isp.pdf|archiveurl=https://web.archive.org/web/20150905081110/http://www.objectmentor.com/resources/articles/isp.pdf|archivedate=5 September 2015|date=1996|website=objectmentor.com|accessdate=2015-09-05|publisher=}}</ref>{{翻訳|汎用なインターフェースが一つあるよりも、各クライアントに特化したインターフェースがたくさんあった方がよい}}</blockquote>この原則下のinterfaceは、様々に機能分化されて細かな用途ごとに定義されることになる。 |
||
<!-- 日本語として文意不明なためCO -- |
|||
この原則は、マーティンなどが提唱した[[インタフェース (抽象型)|インターフェース]][[継承 (プログラミング)|継承]]と[[ポリモーフィズム|サブタイプ多態性]]を重視している方を指している。--> |
|||
=== 依存性逆転の原則（dependency inversion principle） === |
|||
この原則下のclientは、interfaceを通してserviceを利用することになる。<!-- interfaceの実装serviceは、injectorによって適宜決定される。← 一般に言える話ではない。--> |
|||
| ⚫ | <blockquote>High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces), [not] concretions.<ref>{{Cite web|title=Dependency Inversion Principle|url=http://www.objectmentor.com/resources/articles/dip.pdf|archiveurl=https://web.archive.org/web/20150905081103/http://www.objectmentor.com/resources/articles/dip.pdf|archivedate=5 September 2015|website=objectmentor.com|accessdate=2015-09-05|publisher=}}</ref>{{翻訳|上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方とも具象ではなく、抽象（インターフェースなど）に依存するべきである}}</blockquote>この原則は、[[Mixin|Mix-in]]をモチーフにして[[依存性の注入]]などのベースになっている。 |
||
| ⚫ | |||
| ⚫ | |||
<blockquote>Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.<ref>{{Cite web|title=Liskov Substitution Principle|url=http://www.objectmentor.com/resources/articles/lsp.pdf|archiveurl=https://web.archive.org/web/20150905081111/http://www.objectmentor.com/resources/articles/lsp.pdf|archivedate=5 September 2015|website=objectmentor.com|accessdate=2015-09-05|publisher=}}</ref> |
|||
{{翻訳|ある基底クラスへのポインタないし参照を扱っている関数群は、その派生クラスのオブジェクトの詳細を知らなくても扱えるようにしなければならない}}</blockquote>この原則は[[契約による設計]]と関連しており、そこでの事前条件と事後条件が定義された契約が、即ちinterfaceになる。 |
|||
この原則下のclientは、一つのinterfaceを通して、様々な実装serviceを利用できることになる。 |
|||
| ⚫ | |||
| ⚫ | <blockquote>Many client-specific interfaces are better than one general-purpose interface.<ref>{{Cite web|title=Interface Segregation Principle|url=http://www.objectmentor.com/resources/articles/isp.pdf|archiveurl=https://web.archive.org/web/20150905081110/http://www.objectmentor.com/resources/articles/isp.pdf|archivedate=5 September 2015|date=1996|website=objectmentor.com|accessdate=2015-09-05|publisher=}}</ref> |
||
{{翻訳|汎用なインターフェースが一つあるよりも、各クライアントに特化したインターフェースがたくさんあった方がよい}}</blockquote>この原則下のinterfaceは、様々に機能分化されて細かく定義されることになる。 |
|||
| ⚫ | |||
| ⚫ | <blockquote>High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces), [not] concretions.<ref>{{Cite web|title=Dependency Inversion Principle|url=http://www.objectmentor.com/resources/articles/dip.pdf|archiveurl=https://web.archive.org/web/20150905081103/http://www.objectmentor.com/resources/articles/dip.pdf|archivedate=5 September 2015|website=objectmentor.com|accessdate=2015-09-05|publisher=}}</ref> |
||
{{翻訳|上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方とも具象ではなく、抽象（インターフェースなど）に依存するべきである}}</blockquote>この原則は、[[Mixin|Mix-in]]をモチーフにして[[依存性の注入]]などのベースになっている。 |
|||
| ⚫ | |||
== 関連項目 == |
== 関連項目 == |
||
| 52行目: | 41行目: | ||
* [[YAGNI|YAGNI（You aren't gonna need it）]] |
* [[YAGNI|YAGNI（You aren't gonna need it）]] |
||
== |
== 出典 == |
||
<references /> |
<references />{{SOLID (オブジェクト指向設計)}} |
||
[[Category:プログラミング原則]] |
[[Category:プログラミング原則]] |
||
[[Category:オブジェクト指向]] |
[[Category:オブジェクト指向]] |
||
2024年4月17日 (水) 01:57時点における最新版
SOLID（ソリッド）は、ソフトウェア工学の用語であり、特にオブジェクト指向で用いられる五つの原則の頭字語である。ソフトウェア設計をより平易かつ柔軟にして保守しやすくすることを目的にしている。その特徴はインターフェースを仲介にしての機能の使用と、インターフェースによる機能の注入である。
この五つの原則は、アメリカのソフトウェア技術者ロバート・C・マーティンが提唱していた数々の設計原則の中からチョイスされたものである。マーティンが提唱していた原則は、例えば2000年に発表されたレポート『Design Principles and Design Patterns』[1]の中で紹介されている[2][3][4]。そのうち五原則をSOLIDという語呂合わせの頭字語にして普及させたのは、ソフトウェア技術者マイケル・フェザーズであり、2004年以降に広く知られるようになった[5]。SOLIDはオブジェクト指向設計由来であるが、アジャイルソフトウェア開発や適応的ソフトウェア開発といった方法論の哲学にもなっている。
五つの原則
[編集]SOLIDは、次の5つの原則からなる。
- 単一責任の原則 (single-responsibility principle)
- 開放閉鎖の原則（open/closed principle）
- リスコフの置換原則（Liskov substitution principle）
- インターフェース分離の原則 (interface segregation principle)
- 依存性逆転の原則（dependency inversion principle）
単一責任の原則 (single-responsibility principle)
[編集]There should never be more than one reason for a class to change.[6]（→変更するための理由が、一つのクラスに対して一つ以上あってはならない）
これは、every class should have only one responsibility.（→各クラスはそれぞれ一つだけの責務を持つべきである）とも言い換えられる。ここでの責務とは提供機能と同義である。この原則は、clientに特定の機能を提供する役割（role）役者（actor）としてのserviceのクラスに焦点を当てている。
この原則下のserviceは、それぞれ一つの機能または一つの役割しか持てない。この原則下のclientは、機能別に担当serviceを変更することになる。
開放閉鎖の原則（open/closed principle）
[編集]software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.[7]（→ソフトウェアの実体（クラス、モジュール、関数など）は、拡張に対して開かれているべきであり、修正に対して閉じていなければならない）
この原則下のinterfaceはその構成が不変になり、serviceは構成の変化が許される。serviceの構成変化は、継承によるサブクラス定義でなされるのが普通である。
リスコフの置換原則（Liskov substitution principle）
[編集]Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.[8]（→ある基底クラスへのポインタないし参照を扱っている関数群は、その派生クラスのオブジェクトの詳細を知らなくても扱えるようにしなければならない）
この原則下のclientは、一つのinterfaceを通して、様々なserviceクラスを利用することになる。
インターフェース分離の原則 (Interface segregation principle)
[編集]Many client-specific interfaces are better than one general-purpose interface.[9]（→汎用なインターフェースが一つあるよりも、各クライアントに特化したインターフェースがたくさんあった方がよい）
この原則下のinterfaceは、様々に機能分化されて細かな用途ごとに定義されることになる。
依存性逆転の原則（dependency inversion principle）
[編集]High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces), [not] concretions.[10]（→上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方とも具象ではなく、抽象（インターフェースなど）に依存するべきである）
この原則は、Mix-inをモチーフにして依存性の注入などのベースになっている。
この原則下のclientは、専門機能が分離されたモジュールにされる。その下位モジュールは専門機能の扱い方を変えたものにされる。専門機能とは、clientがinterfaceを通して利用するserviceであり、上位clientと下位clientは共に、専門機能interfaceに依存することになる。ここでのclientは具象であり、interfaceは抽象である。
関連項目
[編集]出典
[編集]- ^ Robert C. Martin (2000年). “Design Principles and Design Patterns”. objectmentor.com. 6 September 2015時点のオリジナルよりアーカイブ。2009年1月14日閲覧。
- ^ Robert C. Martin. “Principles Of OOD”. butunclebob.com. 2014年7月17日閲覧。
- ^ Robert C. Martin. “Getting a SOLID start”. objectmentor.com. 2013年8月19日閲覧。
- ^ Sandi Metz (May 2009). “SOLID Object-Oriented Design”. 2019年8月13日閲覧。 Talk given at the 2009 Gotham Ruby Conference.
- ^ Fenton, Steve (2017). Pro TypeScript: Application-Scale JavaScript Development. p. 108. ISBN 9781484232491
- ^ “Single Responsibility Principle”. objectmentor.com. 1 June 2015時点のオリジナルよりアーカイブ。2015年9月5日閲覧。
- ^ “Open/Closed Principle”. objectmentor.com. 5 September 2015時点のオリジナルよりアーカイブ。2015年9月5日閲覧。
- ^ “Liskov Substitution Principle”. objectmentor.com. 5 September 2015時点のオリジナルよりアーカイブ。2015年9月5日閲覧。
- ^ “Interface Segregation Principle”. objectmentor.com (1996年). 5 September 2015時点のオリジナルよりアーカイブ。2015年9月5日閲覧。
- ^ “Dependency Inversion Principle”. objectmentor.com. 5 September 2015時点のオリジナルよりアーカイブ。2015年9月5日閲覧。