デザインパターンについて読んでいます。私はこの原則が何をするか知っています。
高レベルおよび低レベルのクラスは、抽象化に依存しています。しかし、なぜこれがinversionであると言うのですか?
従来のプログラミングでは、ビジネスロジックのフローは、互いに静的に割り当てられたオブジェクトによって決定されます。制御の反転により、フローはアセンブラーによってインスタンス化され、抽象化を通じて定義されているオブジェクトの相互作用によって可能になるオブジェクトグラフに依存します。バインドプロセスは、依存関係の注入によって実現されますが、サービスロケータを使用すると制御が反転することもあると主張する人もいます。
または言い換えると、従来の非反転制御高レベルのコンポーネントは、低レベルのコンポーネントに依存しています。
これは制限として示されています。これは、高レベルのコンポーネントが、環境または低レベルの過度に具体的なコンポーネント以外のものを操作する機会を失うためです。
制御の反転を使用すると、上記のパラダイムが反転します。高レベルのコンポーネントは単なる抽象クラスまたはインターフェースであり、これらは通常、それらを実装するコードに依存しないパッケージまたはアセンブリで宣言されます(そして、そうする必要があります)。そして、高レベルのコード(低レベルのコードは高レベルのインターフェースまたは抽象クラスを実装する必要があるためです)。
これは反転です!
ボブ・マーティンの引用 トピックに関する彼の元の記事 :
私がなぜ「反転」という言葉を使うのか疑問に思うかもしれません。率直に言って、構造化分析や設計などの従来のソフトウェア開発方法では、高レベルのモジュールが低レベルのモジュールに依存し、抽象化が詳細に依存するソフトウェア構造を作成する傾向があるためです。実際、これらのメソッドの目標の1つは、高レベルモジュールが低レベルモジュールを呼び出す方法を記述するサブプログラム階層を定義することです。図1は、このような階層の良い例です。したがって、適切に設計されたオブジェクト指向プログラムの依存関係構造は、従来の手続き型メソッドから通常生じる依存関係構造に対して「反転」しています。
私が理解しているように、反転の原則を適切に設定すると、高レベルのポリシーが具体的なユーティリティコンポーネントではなく抽象化の観点から記述されます。そして、高水準モジュールの観点からは、抽象的なポリシーは安定したままです。低レベルの実装を変更しても、高レベルのモジュールは強制的に変更されません。
「反転」という用語は、アプローチを従来のモデルと区別します。
制御の逆転の直接的な例を示します。
テレビのクラスがあるとします。
class Television {
private Button powerButton;
public Television() {
this->powerButton = new Button();
}
function turnOn() {
this->powerButton->turnOnTV();
}
}
ご覧のとおり、Televisionは低レベルのコンポーネントであるButtonクラスと密接に結合しています。つまり、テレビはオンにするボタンクラスに依存します。
制御の反転により、Television 必須ではないがButtonクラスに依存するようになります。つまり、「テレビはボタンクラスをインスタンス化してはなりません」
解決策は次のようなものです:
class Television {
private ISomethingThatTurnsOnTV thisTurnsOnTV;
public Television(ISomethingThatTurnsOnTV somethingThatTurnsOnTV) {
this->thisTurnsOnTV = somethingThatTurnsOnTV;
}
function turnOn() {
this->thisTurnsOnTV->turnOnTV();
}
}
現在、テレビは、ボタン、リモコン、または人間のジェスチャーがテレビの電源をオンにしていることを認識していません。また、Buttonは、高レベルのコンポーネントであるインターフェースISomethingThatTurnsOnTVを実装する必要があります。
だから私たちはから行きました:
highLevel -----------------------lowLevel
テレビ----依存---->ボタン
に:
lowLevel -------------------------highLevel
ボタン-----依存--------> ISomethingThatTurnsOnTV
そしてテレビはもうボタンに依存していません:D
問題は、いわゆる「依存関係の逆転の原則」の命名と定義が不十分であることです。定義はその作者によって後で明確にされましたが、その名前は完全に誤称です。この原則が適用されるときに反転される依存関係はありません。