「SOLID」の版間の差分
ce 文章整理・一部CO・引用文をblockquoteで表示・引用文の翻訳例をTemplate:翻訳で表示 |
|||
| 9行目: | 9行目: | ||
<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>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>これは |
{{翻訳|変更するための理由が、一つのクラスに対して一つ以上あってはならない}}</blockquote>これは、every class should have only one responsibility.{{翻訳|各クラスはそれぞれ一つだけの責務を持つべきである}}とも言い換えられる。ここでの責務とは提供機能と同義である。この原則は、clientに特定の機能を提供する役割（role）役者（actor）としてのserviceの[[クラス (コンピュータ)|クラス]]に焦点を当てている。 |
||
| ⚫ | |||
この原則は、役割（role）役者（actor）としての[[クラス (コンピュータ)|クラス]]に焦点を当てており、clientから見たserviceが対象である。 |
|||
| ⚫ | |||
=== [[開放/閉鎖原則|開放閉鎖の原則（Open/closed principle）]] === |
=== [[開放/閉鎖原則|開放閉鎖の原則（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>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> |
||
この原則下のclientによって扱われるinterfaceの構成は不変になり、serviceの方は構成の変化が許される。serviceの構成変化は、[[継承 (プログラミング)|継承]]による[[サブクラス (計算機科学)|サブクラス]]定義でなされるのが普通である。 |
|||
<!-- 日本語として文意不明なためCO -- |
|||
この原則は、マーティンなどが提唱した[[インタフェース (抽象型)|インターフェース]][[継承 (プログラミング)|継承]]と[[ポリモーフィズム|サブタイプ多態性]]を重視している方を指している。--> |
|||
この原則下のclientは、interfaceを通してserviceを利用することになる。<!-- interfaceの実装serviceは、injectorによって適宜決定される。← 一般に言える話ではない。--> |
|||
=== [[リスコフの置換原則|リスコフの置換原則（Liskov substitution principle）]] === |
=== [[リスコフの置換原則|リスコフの置換原則（Liskov substitution principle）]] === |
||
<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>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>この原則は[[契約による設計]] |
{{翻訳|ある基底クラスへのポインタないし参照を扱っている関数群は、その派生クラスのオブジェクトの詳細を知らなくても扱えるようにしなければならない}}</blockquote>この原則下のclientは、一つのinterfaceを通して、様々なserviceクラスを利用することになる。この原則は[[契約による設計]]に言及されているので、そのserviceクラスたちは[[継承 (プログラミング)|継承]]関係で結ばれているものになる。 |
||
この原則下のclientは、一つのinterfaceを通して、様々な実装serviceを利用できることになる。 |
|||
=== {{仮リンク|インターフェース分離の原則|en|Interface segregation principle|label=インターフェース分離の原則 (Interface segregation principle)}} === |
=== {{仮リンク|インターフェース分離の原則|en|Interface segregation principle|label=インターフェース分離の原則 (Interface segregation principle)}} === |
||
<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>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>この原則下のinterfaceは、様々に機能分化されて細かな用途ごとに定義されることになる。 |
||
=== [[依存性逆転の原則|依存性逆転の原則（Dependency inversion principle）]] === |
=== [[依存性逆転の原則|依存性逆転の原則（Dependency inversion principle）]] === |
||
| 41行目: | 34行目: | ||
{{翻訳|上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方とも具象ではなく、抽象（インターフェースなど）に依存するべきである}}</blockquote>この原則は、[[Mixin|Mix-in]]をモチーフにして[[依存性の注入]]などのベースになっている。 |
{{翻訳|上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方とも具象ではなく、抽象（インターフェースなど）に依存するべきである}}</blockquote>この原則は、[[Mixin|Mix-in]]をモチーフにして[[依存性の注入]]などのベースになっている。 |
||
この原則下のclientは、専門機能が分離されたモジュールにされる。その下位モジュールは専門機能の扱い方を変えたものにされる。専門機能とは、clientがinterfaceを通して利用するserviceであり、上位clientと下位clientは共に、専門機能interfaceに依存することになる。ここでのclientは具象 |
この原則下のclientは、専門機能が分離されたモジュールにされる。その下位モジュールは専門機能の扱い方を変えたものにされる。専門機能とは、clientがinterfaceを通して利用するserviceであり、上位clientと下位clientは共に、専門機能interfaceに依存することになる。ここでのclientは具象であり、interfaceは抽象である。 |
||
== 関連項目 == |
== 関連項目 == |
||
2021年11月23日 (火) 15:51時点における版
SOLID（ソリッド）は、ソフトウェア工学の用語であり、特にオブジェクト指向で用いられる五つの原則の頭字語である。ソフトウェア設計をより理解しやすく、よりしなやかにして、より保守しやすくすることを目的にしている。
この五つの原則は、アメリカのソフトウェア技術者ロバート・C・マーティンが提唱していた数々の設計原則の中からチョイスされたものである。マーティンが提唱していた原則は、例えば2000年に発表されたレポート「Design Principles and Design Patterns」[1]の中で紹介されている[2][3][4]。そのうち五原則をSOLIDという語呂合わせの頭字語にして普及させたのは、ソフトウェア技術者ミカエル・フェザーズであり、2004年以降に広く知られるようになった[5]。SOLIDはオブジェクト指向設計由来であるが、アジャイルソフトウェア開発や適応的ソフトウェア開発といった方法論の哲学にもなっている。
五つの原則
単一責任の原則 (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のクラスに焦点を当てている。
この原則下のclientは、現行serviceの機能に対して変更を要求する場合は、serviceは一つの不可分な機能しか持てないことから、現行serviceとは別のserviceクラスに変更することになる。
開放閉鎖の原則（Open/closed principle）
software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.[7] （→ソフトウェアの実体（クラス、モジュール、関数など）は、拡張に対して開かれているべきであり、修正に対して閉じていなければならない）
この原則下のclientによって扱われる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クラスを利用することになる。この原則は契約による設計に言及されているので、その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. 2015年9月6日時点のオリジナルよりアーカイブ。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 (2009年5月). “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. 2015年6月1日時点のオリジナルよりアーカイブ。2015年9月5日閲覧。
- ^ “Open/Closed Principle”. objectmentor.com. 2015年9月5日時点のオリジナルよりアーカイブ。2015年9月5日閲覧。
- ^ “Liskov Substitution Principle”. objectmentor.com. 2015年9月5日時点のオリジナルよりアーカイブ。2015年9月5日閲覧。
- ^ “Interface Segregation Principle”. objectmentor.com (1996年). 2015年9月5日時点のオリジナルよりアーカイブ。2015年9月5日閲覧。
- ^ “Dependency Inversion Principle”. objectmentor.com. 2015年9月5日時点のオリジナルよりアーカイブ。2015年9月5日閲覧。