「依存性逆転の原則」の版間の差分

2020年1月10日 (金) 20:24時点における版

2024年7月9日 (火) 10:50時点における最新版

(9人の利用者による、間の13版が非表示)

1行目:

[[オブジェクト指向設計]]において、'''依存性逆転の原則'''、または'''依存関係逆転の原則'''（dependency inversion principle）とは<ref>{{Cite book |和書 |author=ロバート・C・マーチン |title=アジャイルソフトウェア開発の奥義　第2版 |publisher=SBクリエイティブ |page=163 |isbn=978-4-7973-4778-4}}</ref>'''（dependency inversion principle)'''　とはソフ、[[オブジェクトウエア指向設計]]の用語であり、[[モジュールを[[結合度|疎結合]]に保つための特定の形式を指す用語。この原則に従うとソフトウェアの振る舞いを定義する上位レベルのモジュールから下位レベルモジュールへ]]の従来の依存関係は逆転し、[[疎結果として下位レベルモジュールの実装の詳細から上位レベルモジュール合]]を独確立に保つことができするように特別な形態を表現したコンセプトである。こ[[SOLID]]の五原則で述べの一つとして知られていることは以下の２つである:<ref name="Martin2003">{{cite book|last1=Martin|first1=Robert C.|title=Agile Software Development, Principles, Patterns, and Practices|url=https://books.google.com/books/about/Agile_Software_Development.html?id=0HYhAQAAIAAJ&redir_esc=y|year=2003|publisher=Prentice Hall|isbn=978-0135974445|pages=127–131}}</ref>。

[[オブジェクト指向プログラミング|オブジェクト指向]]における従来の依存関係とは、上位モジュールから下位モジュールへの方向性であり、仕様定義を担う上位モジュールを、詳細実装を担う下位モジュールから独立させて、各下位モジュールを別個保存するというものだったが、それに対して依存性逆転原則は以下二点を提唱している<ref name="Martin2003">{{cite book|last1=Martin|first1=Robert C.|title=Agile Software Development, Principles, Patterns, and Practices|url=https://books.google.com/books/about/Agile_Software_Development.html?id=0HYhAQAAIAAJ&redir_esc=y|year=2003|publisher=Prentice Hall|isbn=978-0135974445|pages=127–131}}</ref>。

* ''A. 上位レベルのモジュールは下位レベルのモジュールに依存すべきではない。両方とも[[抽象化 (計算機科学)|抽象]]（abstractions)に依存すべきである。''

* ''B. 抽象は詳細に依存してはならない。詳細が抽象に依存すべきである。''

# 上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方とも抽象（例としてインターフェース）に依存するべきである。<br/>"High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces)."<ref name=":0">{{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>

この上位レベル、下位レベルの''両方とも''抽象に依存しなければならないと言う要求により、この設計原理は一部の人々のオブジェクト指向プログラミングに対する考え方を''反転''させる。<ref>{{cite journal|last1=Freeman|first1=Eric|last2=Freeman|first2=Elisabeth|last3=Kathy|first3=Sierra|last4=Bert|first4=Bates|editor2-last=Loukides|editor2-first=Mike|year=2004|title=Head First Design Patterns|url=http://shop.oreilly.com/product/9780596007126.do|volume=1|pages=|publisher=O'REILLY|accessdate=2012-06-21|format=paperback|isbn=978-0-596-00712-6|authorlink1=|authorlink2=|authorlink3=|authorlink4=|editor1-last=Hendrickson|editor1-first=Mike|editor-link1=|editor-link2=}}</ref>

# 抽象は詳細に依存してはならない。詳細（具象的な実装内容）が抽象に依存するべきである。<br/>"Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions."<ref name=":0" />

この上位レベモジュール、と下位レベモジュールの''両双方とも''が抽象に依存しなければならないと言いう要求により内容は、この設計原理は一部それまでの人々のオブジェクト指向プログラミングに対する考え方の常識を''反転''させ覆している。ものだった<ref>{{cite journal|last1=Freeman|first1=Eric|last2=Freeman|first2=Elisabeth|last3=Kathy|first3=Sierra|last4=Bert|first4=Bates|editor2-last=Loukides|editor2-first=Mike|year=2004|title=Head First Design Patterns|url=http://shop.oreilly.com/product/9780596007126.do|volume=1|pages=|publisher=O'REILLY|accessdate=2012-06-21|format=paperback|isbn=978-0-596-00712-6|authorlink1=|authorlink2=|authorlink3=|authorlink4=|editor1-last=Hendrickson|editor1-first=Mike|editor-link1=|editor-link2=}}</ref>。

この原理について述べた上記のポイント A と B の背景にある考えは、上位モジュールと下位モジュールの相互作用を設計する際に、これらの関係が抽象的な相互作用として捉えられるべきであるということであり、これによって上位モジュールだけでなく下位レベルモジュールも設計的な影響を受けることになる。下位モジュールは相互作用を念頭に設計されるべきで、その結果自身を使用するためのインターフェースについて変更を行う必要が生じる可能性がある。多くの場合、相互作用を抽象的な概念として捉えることにより追加のコーディングパターンを導入せずにコンポーネント間の結合を減らすことができ、より軽量で実装への依存が少ない総合作用スキーマを用いるだけで済むようになる。

この原理について述べた上記のポイント A と B 二点の背景にある考えとは、上位モジュールと下位モジュールの相互作用を設計する際には、これらその関係が抽象的な相互作用として捉自体も抽象的に考えられるべきで必要があるということであり、これによってる。上位モジュールの抽象化だけではなく下位レベルモジュールも設計的な影響、それを受け詳細化することになる。下位モジュールは相互作用を念頭に設計されるべきでへの見方も変えて、その結果自身を使用するためのインターフェースにつの使いて方も変更を行う必要が生じえる可能性があことを求めている。多くの場合、相互作用を抽象的な概念としてに捉えることによりは、追加のコーディングパターンを導入せずに増やすことなくコンポーネント間の結合を減らすせることに繋ができ、る。これはより軽量で小規模な実装への依存が少ない総合性相互作用スキーマを用いるだけで済むようにな実現する。

２つのモジュールの間で見出された抽象的な相互関係が一般性を持ち、かつ一般化が意味を持つとき、この設計原理は以下の依存性の逆転コーディングパターンを導く。

２つのモジュールの間で見出された抽象的な相互関係が一般性を持ち、かつ一般化作用スキーマが汎用的な意味を持つときなしているならば、この設計原理則は以下の依存性の逆転のコーディングパターンを適切な方向に導く。

== History歴史 ==

依存性逆転の原則は、アメリカのソフトウェア技術者{{仮リンク|ロバート・C・マーティン|en|Robert C. Martin|label=}}によって確立され、彼の論文「オブジェクト指向設計品質指標 - Object Oriented Design Quality Metrics」内の「依存性の分析 - an analysis of dependencies」節を含んだ2000年以降の数々の出版物に記載されていた<ref>{{Cite web|url=https://linux.ime.usp.br/~joaomm/mac499/arquivos/referencias/oodmetrics.pdf|title=Object Oriented Design Quality Metrics: An analysis of dependencies|access-date=2016-10-15|last=Martin|first=Robert C.|date=|website=|publisher=|publication-date=October 1994}}</ref>。「Agile Software Development, Principles, Patterns, and Practices」「Agile Principles, Patterns, and Practices in C#」などのアジャイル系がよく知られる。

依存性逆転の原則と銘打たれたのは、1996年5月のC++研究論文の記事内とされている<ref>{{Cite web|url=http://www.objectmentor.com/resources/articles/dip.pdf|title=The Dependency Inversion Principle|access-date=|last=Martin|first=Robert C.|date=May 1996|publisher=C++ Report|archiveurl=https://web.archive.org/web/20110714224327/http://www.objectmentor.com/resources/articles/dip.pdf|archivedate=2011-07-14|url-status=dead|url-status-date=2018-11-12}}</ref>。

== 従来のレイヤーパターン ==

48 ⟶ 55行目:

* 全ての変数のインスタンス化において[[Factory Method パターン|Factory Method]]もしくは{{仮リンク|Factory パターン|en|Factory (object-oriented programming)}}のような{{仮リンク|生成に関するパターン|en|Creational pattern}}の実装が必要になる。もしくは[[依存性の注入|DI]]フレームワークが必要になる。

=== インターフェース・モック化の制約 ===

継承ベースのモック化ツールを使用した場合でも以下の制約が生じる。

* 外部公開されている静的メンバーも体系的に依存性性注入されるべきだが、そのための実装はかなり難しい。

* テスト可能な全てのモジュールはインターフェースの実装、もしくは抽象定義のオーバーライドを行う必要がある。

63 ⟶ 70行目:

DIPの２つの一般的な実装では、さまざまな意味でよく似た論理アーキテクチャを使用する。

直接的な実装において、 plicypolicy クラスと service 抽象クラスは一つのライブラリーにパッケージ化される。この実装では上位コンポーネントと下位コンポーネントは別々のパッケージ/ライブラリとして配布される。上位レベルコンポーネントによって要求されるされる振る舞い/サービスを定義した[[インタフェース (抽象型)|インターフェース]]は上位レベルコンポーネントによって所有され、上位レベルコンポーネントと同じライブラリの中に存在する。

上位レベルコンポーネントのインターフェースは下位レベルコンポーネントによって実装されるため、コンパイル時に下位レベルコンポーネントが上位レベルコンポーネントに依存する事が必要になる。よって従来の依存関係は逆転する。

71 ⟶ 78行目:

Figures 1 and 2 では同じ機能を実現したコードを表現している。しかし、 Figure 2 ではインターフェースは依存性を逆転させるために使用されている。policy コードの再利用性を最大化したり、循環依存を排除するために依存の方向は選択することができる。

このバージョンの DIP では、下位レイヤーコンポーネントが上位レベルレイヤーのインターフェース/抽象に依存しているため、下位レベルレイヤーの再利用は困難になる。 この実装はその変代わりに伝統的な to-to-bottom の依存関係を反対の bottom-to-top へと逆転させる。

抽象コンポーネントをライブラリやパッケージから独立させて置くと、より柔軟性が増す。

77 ⟶ 84行目:

[[ファイル:DIPLayersPattern_v2.png|中央]]

全てのレイヤーを分離して個別のパッケージに置くことでどのレイヤーの再利用性も向上し、ロバストネス性とモビリティーを得ることができる.。<ref name="Martin2003" />

== 例 ==

=== 家系モジュール ===

ある家系システムでは人々の間の関係を第一レベル関係のグラフとして表現するかもしれませんない(父親/息子, 父親/娘, 母親/息子, 母親/娘, 夫/妻, 妻/夫...)。これは非常に効率的ですある(そして拡張も可能: 元夫/元妻, 法的保護者...)。

しかし、上位レベルモジュールでは家系をブラウズするためのより簡単な方法が必要になるかもしれませんない: 人には、子供、父親、母親、兄弟と姉妹(異母兄弟を含む含まないも合わせて）、祖父、祖母、伯父、伯母、従兄弟... などがいるかもしれませんない。

家系モジュールの使用法に応じて、共通の関係を明確で直接的な属性として（グラフを隠して）表示することは上位レベルモジュールと家系モジュールの間の結合を遥かに軽くでき、モジュールの使用になんの影響も与えることなく内部表現を完全に変更することを可能にしまする。またそれによって、家系モジュールに対し兄弟、姉妹（異母兄弟であるかどうか）の正確な定義を埋め込む事が可能になりまする... またそれは[[単一責務の法則]]を強制することにも繋がりまする。

最終的に、もし最初の一般化された拡張可能なグラフアプローチが一番拡張可能に思えるのであれば、家系モジュールの利用は更に特殊化及び単純化された関係の実装がアプリケーションに対して十分であることを示しているかもしれませんないし、より効率的なシステムを作成する手助けになるかもしれませんない。

この例でのモジュール間の相互関係の抽象化は下位レベルモジュールのインターフェースの単純化だけでなく、より単純化された実装につながるかもしれませんない。

=== リモートファイル・サーバークライアント ===

リモートファイルサーバー(FTP, cloud strage ...)に対するクライアントを実装しなければならないケースを想像してくださいせよ。あなたはそのクライアントに抽象インターフェースを持たせる事を考えるでしょだろう。

# Connection/Disconnection (a connection persistence layer may be needed)

102 ⟶ 108行目:

# File history management ...

ローカルファイル、リモートファイルの両方が同じ抽象インターフェースを提供する場合、ローカルファイルと完全に実装された依存性逆転パターンを使用するどんな上位レベルモジュールもローカルとリモートの区別なくファイルにアクセスすることが可能になりまする。

ローカルディスクは一般的にフォルダーを使用します、リモートストレージもフォルダーを使用するかもしれませんない(もしくはタグのみ、フォルダーとタグの両方など）.。 もし可能であればそれらを統一する方法を決めておく必要がありまする。

リモートファイルに対しては、作成と置換のみを行う必要があるかもしれませんない(ローカルファイルに比べてリモートファイルのランダムアップデートはあまりに遅く、実装も難しくなる可能性があるので、リモートファイルの更新は意味をなさない)。リモートファイルに対して部分的な読み込みと書き込みを行う必要があるかもしれませんない（少なくともリモートファイルモジュールの内部では通信中断後のダウンロードとアップロードの再開をできるようにする必要がある）。しかし、ローカルキャッシュを利用している場合を除き、ランダムリードは適しませんさない。

ファイル検索は "pluggable" であるかもしれません:ない ファイル検索は OS、特にタグや全文検索に依存し、異なるシステムでも実装する事ができまする。(OS に組み込まれていたり、別に入手する事も可能) 並行実行される置換または削除の検出は、他の抽象インタフェースに影響を与える可能性がありまする。

概念的なそれぞれのインターフェースに対してリモートファイルサーバーを設計するときは、上位レベルモジュールが要求するサービスのレベル (必ずしも全てが要求されるわけではない）を良く考える必要がありまする。そして、どのようにリモートファイルサーバーの機能を実装するかだけでなく、アプリケーション内に既に存在するファイルサービス（ローカルファイル、既にあるクラウドクライアントなど）と新たしいリモートファイルサーバークライアントの間で整合を取るかについても同様に考える必要がありまする。

必要なインターフェースの設計が完了したら、リモートファイルサーバークライアントはこれらのインターフェースを実装すべきですある。

また、既に存在するローカルファイルに対しての機能 (例えばファイル更新など）について制限を加えたい場合、同じ抽象インタフェースを提供するローカルまたは他の既存のリモートファイルアクセスモジュール用のアダプタを記述する必要があるかもしれませんない。また、コンピュータ上に構成されている利用可能なファイル互換システムを検索するために独自のファイルアクセス列挙子を記述しておく必要もありまする。

これらが完了すると、アプリケーションはドキュメントをローカルとリモートに透過的に保存する事が可能になりまする。さらに簡単に言うと、新しいファイルアクセスインターフェースを使用している上位レベルモジュールは使用の際にローカルとリモートファイルにアクセルするシナリオを意識する必要がなくなり、再利用性が向上しまする。

注意: 多くの OS がこの手の機能を実装し始めているため、新規実装のクライアントをこの既に存在している抽象モデルへ適用するのは控えた方が良いかもしれませんない。

この例では、モジュールを抽象インターフェースのセットとして考え、このインターフェースのセットに他のモジュールを適合させることで、様々なファイルストレージシステムに対し、共通のインターフェースを提供する事ができまする。

=== Model View Controller ===

[[ファイル:DIP_concrete_example.png|中央|Example of DIP]]

UI とアプリケーションレイヤーパッケージは主に具象クラスを含んでいて、コントローラーは抽象/インターフェース型を含んでいまする。また UI は ICustomerHandler のインスタンスを保持し、全てのパッケージは物理的に分離されていて。アプリケーションレイヤーには Page クラスが使用する具象クラスの実装が存在していまする。これらのインターフェースのインスタンスは （コントローラーと同じパッケージに存在するかもしれない）Factory によって動的に生成されまする。具象タイプである Page と CustomerHandler はお互いに依存してはらなず、両方とも ICustomerHandler に依存しまする。

これらの直接的な効果は、UI が直接 ApplicatonLayer や、ICustomerHandler を実装したどの具象パッケージも参照する必要がない事ですある。コンクリートクラスはリフレクションを使用してロードされまする。またどの時点であっても、具象実装は UI クラスに変更を及ぼさずに他の具象実装に差し替える事ができまする。他の興味深い可能性は Page クラスが ICustomerHander のメソッドに引数として渡す事ができるインターフェース IPageViewer を実装していると言う事で、これによってt具象実装は具象的な依存なしに UI と通信する事ができまする。何故なら両者はインターフェースでリンクされているからですある。

== 関連するパターン ==

依存性逆転の原則の適用はアダプターパターンの一例と見ることもできまする。例えば、上位レベルクラスが自身が依存する抽象への固有のアダプターインターフェースを定義するような場合がそれに当たりまする。アダプティーの実装はまたアダプターインターフェスに依存しますが（もちろん、このインターフェースを実装しているので）独自の下位レベルモジュール内のコードを用いて実装を行うこともできまする。上位レベルモジュールは、アダプティーとその下位レベルモジュールによって実装されたインターフェースへのポリモーフィックな関数を呼び出すことによってアダプターインターフェースを介して間接的に下位レベルモジュールを利用するため、上位レベルモジュールが下位レベルモジュールに依存するといったことはありませんない。

Plugin, [[Service Locator パターン|Service Locator]], or [[依存性の注入|Dependency Injection]] などの様々なパターンは上位レベルコンポーネントに対する選択された下位レベルコンポーネントの "run-time provisioning" を容易にする目的で導入されます。

Plugin, [[Service Locator パターン|Service Locator]], or [[依存性の注入|Dependency Injection]] などの様々なパターンは上位レベルコンポーネントに対する選択された下位レベルコンポーネントの "run-time provisioning" を容易にする目的で導入されまする。

== History ==

The dependency inversion principle was postulated by [[Robert C. Martin]] and described in several publications including the paper ''Object Oriented Design Quality Metrics: an analysis of dependencies'',<ref>{{Cite web|url=https://linux.ime.usp.br/~joaomm/mac499/arquivos/referencias/oodmetrics.pdf|title=Object Oriented Design Quality Metrics: An analysis of dependencies|access-date=2016-10-15|last=Martin|first=Robert C.|date=|website=|publisher=|publication-date=October 1994}}</ref> an article appearing in the C++ Report in May 1996 entitled ''The Dependency Inversion Principle'',<ref>{{Cite web|url=http://www.objectmentor.com/resources/articles/dip.pdf|title=The Dependency Inversion Principle|access-date=|last=Martin|first=Robert C.|date=May 1996|publisher=C++ Report|archiveurl=https://web.archive.org/web/20110714224327/http://www.objectmentor.com/resources/articles/dip.pdf|archivedate=2011-07-14|deadlinkdate=2018-11-12}}</ref> and the books ''Agile Software Development, Principles, Patterns, and Practices'', and ''Agile Principles, Patterns, and Practices in C#''.

== 脚注出典 ==

{{Reflist}}

144 ⟶ 146行目:

* [[Adapter パターン]]

* [[依存性の注入]]

* [[契約プログラミング|契約による設計]]

* [[インタフェース (情報技術)]]

* [[制御の反転]]

* [[プラグイン]]

* {{仮リンク|Service locator patternサービスロケータパターン|en|Service locator pattern}}

* [[SOLID]]

* [[SOLID]]：the "D" in "SOLID" stands for the dependency inversion principle

* [[インベンターのパラドックス]]

== 外部リンク ==

157 ⟶ 160行目:

* [http://martinfowler.com/articles/dipInTheWild.html DIP in the Wild, Brett L. Schuchert, May 2013]

* [http://blog.sebaslab.com/tag/dependency-injection/ IoC Container for Unity3D – part 2]

{{SOLID (オブジェクト指向設計)}}

{{デフォルトソート:いそんせいきやくてんのけんそく}}

<!--Categories-->

[[カテゴリCategory:ソフトウェアパターン]]

{{デフォルトソート:いそんせい}}

[[カテゴリ:ソフトウェアパターン]]

[[Category:プログラミング原則]]